signal-bot/DOCS-reload.md
Krzysztof kuhy Rudnicki 0717df646a
Some checks are pending
CI / check (push) Waiting to run
CI / web (push) Waiting to run
Rebuild the command table on demand, and survive a tag whose file is gone
The registry used to be built once, inline in build_bot, so every change to
the data behind it -- a person tagged in the web UI, an alias, soon a command
switched off from the management page -- meant restarting the unit. That is
cheap and lossless, but it is a deploy step somebody has to remember, and a
21:37 report can land in the middle of it.

Now the registration sequence lives in wiring.build_registry, and
RegistryHolder runs it again on POST /_reload: the new table is built whole
and swapped in with one assignment, never patched in place, so a duplicate
trigger is found before anything the dispatcher reads has changed. Bad data
(ConfigError, DuplicateTriggerError) keeps the previous table and answers
409 with the reason; a programming error still surfaces as a 500.
scripts/reload.sh wraps it, with --code for the restart a Python change
needs, and an optional command to type in testbot so "reloaded" means
"answered". No Python hot-reload on purpose.

The loader change is what makes deploying this safe: two rows in the live
tags.json name files that are no longer in media/, and load_pack refused
them, so the next restart would have looped on ConfigError. A stale tag is
drift in a file a page edits mid-session, not a broken album -- it is now
skipped with a warning naming it. A tag that reaches outside the album is
still refused. pack_load.py split at the 250-line cap; pack_tags.py is the
half whose checks are not all fatal.

Proven offline in scripts/e2e.sh: !delta is unknown, a fifth person is
tagged into the synthetic pack, scripts/reload.sh runs, and the same
process posts delta's photo.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-04 10:14:39 +02:00

2.8 KiB

Picking up a change without a restart

Two kinds of change reach the running bot, and they are handled differently.

Data: POST /_reload

Aliases, an album's people.json/tags.json, and every setting a page in the management UI writes are data. The command table is built from that data by one function (signal_bot/wiring.py), and RegistryHolder can run it again: the new table is built whole, then swapped in with a single assignment. Nothing restarts, the websocket stays up, and no frame is lost or replayed.

scripts/reload.sh                 # rebuild the table, report how many commands are live
scripts/reload.sh '!nowaosoba'    # ...and then type that at the bot in testbot

The answer is what the bot is serving now:

status code meaning
reloaded 200 the new table is live; commands is its size
kept 409 the data no longer builds; the previous table is still answering, and reason says what was wrong
connecting 503 the bot has not reached Signal yet; there is no table to rebuild

A rejected reload is deliberate: the builder reads files people edit by hand and pages write mid-session, and the only safe answer to a file that does not load is the table that was already answering. Only bad data is survived (ConfigError, DuplicateTriggerError); a programming error still surfaces as a 500 and a traceback in the journal, because a bug is not a file.

Startup is the one time a bad table is fatal: there is nothing to fall back on, and Restart=always looping on a ConfigError is a clearer signal than a bot that answers nothing.

Code: scripts/reload.sh --code

A Python change needs the process replaced. The restart is about a second and lossless (signal-cli replays what arrived meanwhile), but it is a deploy step, so it is the flag rather than the default:

scripts/reload.sh --code '!pomoc'

restarts the unit, waits for /healthz to report ok again, prints the version it came back as, and -- with a command given -- types it in the test group so "restarted" means "answered". There is no hot-reload of Python on purpose: importlib.reload leaves every object the old module already created bound to the old classes, which is a bug that looks like a feature until the first isinstance check.

Proven where

scripts/e2e.sh brackets a scripts/reload.sh with the two scenarios in fake_signal/proofs/: !delta is unknown, a fifth person is tagged into the synthetic pack, the script runs, and the same process posts delta's photo. The route itself is covered in tests/test_app.py, the holder in tests/test_registry_holder.py, and the album case in tests/test_bot.py.