3.0 KiB
type, title, description, tags, timestamp
| type | title | description | tags | timestamp | ||||
|---|---|---|---|---|---|---|---|---|
| guide | Runtime Verification Guide | Tester workflow for validating root cron startup, unprivileged bot execution, retry events, and persistent data behavior. |
|
2026-08-04T20:44:00Z |
Setup
-
Copy
.env.exampleto.envand provide valid required values. -
Build and start the service:
docker compose up --build -d -
Follow container output:
docker compose logs -f bot
Expected Runtime Behavior
The container remains running with cron -f as its foreground process. Startup output includes the configured RUN_AT and TZ. The scheduled cron command invokes /usr/local/bin/run-bot.sh, which runs the Python bot as user bot, not root.
The host ./data directory should contain the synchronized blog/ clone and, after the state store is loaded, posted.json. Both are under the one /app/data mount.
Manual Run
Run the same application command without waiting for cron:
docker compose exec bot /usr/local/bin/python -m tenbackward
A valid run exits 0. A configuration failure exits 2; an exhausted pipeline retry budget exits 1.
Retry Checks
To exercise transient failure handling, use a test repository or injected test double that fails once and then succeeds. Verify JSON events contain:
| Event | Expected fields |
|---|---|
retry_attempt |
operation, attempt, and the original error text. |
retry_exhausted |
Final operation, total attempts, and error text when all attempts fail. |
run_complete |
Counters and posted_ids only after a successful pass. |
With MAX_RETRIES=0, one attempt is still made and no sleep occurs. With a larger value, delays occur only between attempts and follow powers of two beginning at one second.
Configuration Checks
Remove a required variable from .env and restart the service. The entrypoint should report the missing variable before cron starts. If the shell check is bypassed and the Python module runs directly, configuration_error should identify the missing key and return exit code 2 rather than silently substituting an application default.
Persistence and Failure Safety
After a successful publication, inspect /app/data/posted.json and confirm new relative post paths appear under the posted list. If Mastodon publishing fails, the path must not be recorded; a later retry should be able to publish it again.
Key Visual/Observable Elements
This service has no graphical UI. Test-facing outputs are:
- Container status and
docker compose logsoutput. - JSON-per-line startup, retry, failure, and completion events.
- Exit codes from manual runs.
/app/data/blogand/app/data/posted.jsonon the mounted host directory.