mirror of
https://github.com/kuhyx/signal-bot.git
synced 2026-11-11 13:57:32 +01:00
Krzysztof kuhy Rudnicki
0717df646a
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>
60 lines
2.8 KiB
Markdown
60 lines
2.8 KiB
Markdown
# 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.
|
|
|
|
```sh
|
|
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:
|
|
|
|
```sh
|
|
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`.
|