mirror of
https://github.com/spantaleev/matrix-docker-ansible-deploy.git
synced 2026-08-29 12:03:14 +00:00
Slavi PantaleevandClaude Opus 5
0ae18e7a16
A bot rather than a bridge, and not an appservice: it logs into the homeserver as an ordinary user with a password, and keeps its reminders in a local SQLite database. That makes it a cheap second data point for the bot shape, and it is closer to matrix-alertmanager-receiver than to the bridges - except that it has no HTTP surface at all, so there is nothing to probe. What the scenario proves instead: - The unit is active and has not restarted. The bot parses its config file before its own catch-all retry loop starts, so anything wrong in what the role rendered surfaces as a crash loop rather than as a running process. - The bot reached "Logged in as @molecule.reminder-bot:molecule.local" in the journal. That line is only reached once the login call came back as something other than an error, so it covers the homeserver URL, the user ID and the password the role rendered in one go - a real login round-trip against the shared stub, which already answers /_matrix/client/v3/login with an access token. No stub changes were needed. - The SQLite database landed at the path the role configured, owned by the role's uid, with the role's own default name (bot.db) absent as a negative control - so the storage configuration reached the running process and not just the file on disk. - matrix-nio populated its encryption store under the role's data path, inside an otherwise read-only container. - The container runs as the playbook context's uid:gid with the configured timezone on TZ, and carries the version defaults/main.yml pins. - `..._configuration_extension_yaml` was merged over the role's template: device_name is hardcoded in the template, so overriding it is only possible through the extension. Every value the scenario sets differs from both the role's defaults and the bot's own fallbacks - localpart, command prefix, timezone, database filename, both the allowlist and the blocklist. Falsified by pointing the homeserver URL at a dead port. The service stayed `active` with NRestarts == 0 and that assertion passed, because the bot catches every exception and retries every 15s rather than exiting - a good illustration of why `active` on its own proves nothing here. The run failed at "Assert the bot logged in as the user the role configured", which is the assertion carrying the weight. Surprise worth recording: the journal is read through a grep rather than a `--lines=N` tail. The startup lines are the oldest in the journal, and if the stub ever answers /sync instantly the bot's sync loop spins fast enough to bury them under thousands of lines within a minute. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT