They were hard-wrapped at 80 characters, broke mid-parenthesis, and spent lines
restating what the code below them does.
Rewrapped at natural boundaries instead, with the narration dropped and only the
reasons, gotchas and surprises kept. Section dividers stay - they delineate long
plays rather than narrate them.
Comments only; no scenario behaviour changes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT
baibot is the first bot rather than a bridge, and the shape
differs from the appservices: it is a plain Matrix client that logs in with a
password, sets up its profile and then syncs. It publishes no port, so nothing
can be probed over HTTP; what it says about itself in the journal is the only
window into whether the role's configuration reached the process.
What the scenario proves:
- The unit is active with no automatic restarts, AND baibot got past startup
into its sync loop. The second half is what carries the scenario. baibot never
exits when startup goes wrong - it retries the failing step forever with a
growing delay - so the unit sits there `active` with `NRestarts` at 0 while
the bot is permanently half-started. Pointing `user.avatar` at a file that is
not there reproduces exactly that: the unit assertion still passes, the sync
assertion does not.
- The display name the bot announces it wants is the role's `user.name`, which
is neither the role's default nor what the stub reports the account already
has.
- The rendered `logging` string took effect per target: baibot's own records
appear at DEBUG (the role ships `info`) while everything underneath stays at
the `warn` catch-all. The second half is the control, and raising the
catch-all turns 2 DEBUG records into 161.
- The rendered config carries the scenario's homeserver, identity, command
prefix, admin patterns and user patterns, and uses password authentication
exclusively, with the access-token keys rendered as nulls.
- The statically-defined agent survived the provider templating - the
per-provider template rendered to YAML, parsed, merged and nested into the
list - key by key.
- The container runs as the uid/gid the playbook supplies (1234, not the 1000
the base image already has), on the image version defaults/main.yml pins, and
could write its session into the data path.
No AI provider is contacted and none is needed. baibot calls a provider only
when a message asks an agent to do something, so a static agent with a
placeholder key and a base URL that resolves nowhere still has to survive the
bot's startup parsing - which is the part worth testing.
The shared stub grew what a syncing Matrix client needs and an appservice did
not: /sync (with a `next_batch`, and holding the call open for the timeout the
client asked for, or the bot spins the stub in a hot loop), the media config
and upload endpoints a bot setting its own avatar insists on, /keys/upload with
its key counts, and filter creation. Without the media config in particular,
baibot never gets past profile setup.
The shared stub task gained a STUB_VERBOSE knob. The stub already advertised
the environment variable but there was no way to set it from a scenario, and
for a component with no port of its own its request log is the only place to
see what the component is actually asking for.
Note: molecule-shared/homeserver-stub.py also carries a loosened /login match
from another scenario being written in this same tree at the same time; it was
already in the working copy and is not mine.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT
Components here contact a homeserver while starting up and exit if it is
unreachable, so nearly every scenario will need one. Standing up a real
Synapse per role would dominate the run and drag in Postgres, and these
scenarios are not testing Synapse.
The stub answers the handful of endpoints components touch during startup
with the blandest plausible response, and is deliberately permissive: an
unrecognised path returns {} rather than 404, because the goal is to get the
component past its startup checks. It is not an authentication check or a
room state machine, and a scenario should not assert *about* it - if one
starts needing it to behave like a real homeserver, that scenario has
outgrown what these tests are for.
matrix-alertmanager-receiver now includes it instead of carrying its own
inline copy. Verified green afterwards.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Slavi PantaleevandClaude Opus 5