MB680 adds durable observability to Mediabot’s updater without changing the updater’s actual deployment mechanics.
The final commit is:
Version : 3.4dev-20260822_054229
Commit : 6115353
Branch : master
🕰️ Give the Updater a Memory Without Changing the Time-Turner
The purpose of this round is simple:
After an update attempt, an operator should be able to answer what happened without depending on GitHub, temporary markers, or process memory.
Before MB680, Mediabot could report update completion after restart through a transient marker, but that state was consumed and removed. A later update status therefore had no durable history to inspect.
MB680 fixes that gap.
The existing update commands retain their responsibilities:
update
update check
-> remote update diagnostic
update now
-> existing deployment path
update status
-> durable local status only
The important change is that:
update status
is now strictly local.
It does not need GitHub. It does not run update eligibility checks. It does not start the updater. It does not mutate the installation.
This makes it useful even when the remote service is unavailable.
MB680 introduces a persistent JSON state file outside the rotating application directory:
/home/mediabot/.mediabot_v3.update-status.json
Keeping the record next to the deployment tree rather than inside mediabot_v3 means it survives directory rotations performed by the updater.
The durable state can record:
running
success
failed
rolled_back
with operational metadata such as:
phase
started_at
finished_at
updater_pid
old_version
target_version
installed_version
detail
This gives operators the version trail they previously lacked:
old -> target -> installed
The status record is written atomically using a temporary file followed by rename.
The implementation also keeps the status private through a restrictive umask.
The file is operational metadata only.
It is not intended to contain:
passwords
tokens
credentials
secrets
No database or schema change was introduced.
MB680 also removes an obsolete help line claiming that the IRC update command was disabled.
That statement no longer matched the actual product behaviour and was therefore misleading to operators.
A new regression contract was added:
t/cases/882_mb680_durable_update_status.t
The focused updater group covered:
814
815
816
825
829
858
882
Server result:
PASSED : 218/218 (2s)
perl t/test_commands.pl --fast --progress
Result:
Selected: 323 of 765 discovered test file(s)
[====================] 100% [323/323 files | 5982 tests]
PASSED : 5982/5982 (65s)
The development instance was restarted with the MB680 code loaded.
Result:
mediabot@dev : active
Partyline : 0.0.0.0:23456 LISTEN
Smoke : RC=0
The smoke path still returned:
Mediabot Partyline
Please enter your nickname.
Enter your password.
No obvious runtime error was detected in the service journal.
Before any updater run had created a durable record, the local reader correctly returned:
OK: no durable update record yet
STATUS: no update status recorded
RC_LOCAL_STATUS=0
This is intentional.
MB680 does not manufacture a fictional history from Git state or old transient markers.
The first real update run will create the durable operational record.
The security audit remained fully green:
RC_AUDIT=0
Verdict: GO — all 11 security invariants hold.
perl t/test_commands.pl --progress
Result:
[====================] 100% [765/765 files | 15400 tests]
PASSED : 15400/15400 (212s)
MB680 modified:
Mediabot/Mediabot.pm
Mediabot/Update.pm
install/deploy_update.sh
VERSION
and added:
t/cases/882_mb680_durable_update_status.t
Commit summary:
5 files changed
512 insertions
6 deletions
The updater already knew how to perform updates.
What it lacked was memory.
MB680 separates two operator questions that should never have been conflated:
Is an update available?
and:
What happened during the last update?
The first may require the network.
The second should not.
That distinction is now explicit.
The durable record is now available for other operational tooling.
A logical next round is to let doctor consume this information and detect situations such as:
last update failed
rollback occurred
update still marked running unexpectedly
target version differs from installed version
runtime version appears inconsistent with recorded update result
That work should remain a separate round.
MB680 itself is complete and intentionally does not turn doctor into a larger observability project.
🕰️ The Time-Turner still turns exactly the same way. Now it remembers where it went.
You must be logged in to reply.