Titanium Devops Release Notes

Titan starts on a machine where no Tiiny answers. In 0.1.17 it did not: the search found nothing, and the app exited saying "Cannot read configuration; check config.json and your command-line settings." config.json was fine. The real reason was a refusal that said no Tiiny was found, and the sentence about config.json was printed over it.

That was a dead end with no way out. Settings > Model is where you type your device's address, and you cannot reach Settings if the console never comes up. Titan now starts anyway and says so, in the terminal and in the farm's log:

No Tiiny found on this machine, its USB links or its network. Titan is starting anyway. Open Settings > Model to enter the address, or run farm device and start it again.

A device that was never set up is no longer told to "check its address", which is no help to somebody who has never given one, and it is never called: nothing is sent to an address nobody chose.

A refusal now says its own sentence. Only a configuration that genuinely cannot be read gets the sentence about configuration.

This was found by the farm's own field check on Windows and it was never a Windows bug. It is what happens anywhere no Tiiny answers, and every check this project had ran the app through the selfcheck, which uses the echo model and never looks for a device. There is now a test that starts the app exactly the way the farm starts it, with a data directory in the environment, a port on the command line and no device, and waits for it to answer. Run against 0.1.17 it fails with the same line the tester saw.

Verified on GitHub's ubuntu, macOS and Windows runners: 167 tests, the farm's start path and the offline selfcheck pass on all three.

Titanium Tiiny Bot now runs on Windows. 0.1.16 stopped at its first import there, on import fcntl, which is POSIX only, so a person who installed it through the launcher got a traceback instead of an app. Both file locks now go through a small shim: flock on POSIX, msvcrt on Windows, with a refused lock looking the same to every caller.

Four more things behind it would have failed next: the memory reading in Settings, the O_NOFOLLOW flag on six file opens, the lock file's permissions, and a liveness probe that on Windows would have killed the process it was asking about.

The app had never been run on Windows by anything, so this release also adds CI on Linux, macOS and Windows, which found three more:

Text files were read with the machine's own encoding. On Windows that is cp1252, which cannot decode the seed files, so the app crashed again as soon as the lock fix let it get that far.

Memory recall returned nothing at all on Windows, silently. Saved facts were recorded with a backslash path that the code matching on "memory/log/" could never match, so every fact fell out of the prompt while the console still listed them.

Starting up waited on a reverse DNS lookup of the address being bound. That measured 35 seconds on one machine, against a 5 second budget, and it was never a Windows problem: a laptop on a slow network is the same machine.

Verified on GitHub's ubuntu, macOS and Windows runners: 162 tests and the offline selfcheck pass on all three. The Windows selfcheck starts in 2.1 seconds and answers a turn. Nobody has yet run this on a real Windows machine beside a real Tiiny.