Version: 3.4dev-20260820_034834
Commit: 3033b28
Commit message: 🦉 Let the Owl Confirm the Update After the Bot Returns

Mediabot already knew how to update itself with:

m update now

But there was one awkward gap in the workflow.

The command could tell you that the updater had started, then the bot would restart cleanly behind ZNC — which is exactly what we want for a quiet reconnect — but after the new process came back, IRC had no explicit confirmation that the deployment had really succeeded.

MB673 closes that gap.

---

🔄 Before MB673

A typical update looked like this:

<Te[u]K> m update now
<mediabot> Updating now...
<mediabot> updater started - progress in ...

Then:

[restart]

ZNC hides most of the IRC noise, so from the channel point of view the bot simply disappears and returns.

That is pleasant operationally, but it leaves one unanswered question:

Did the update actually complete, and which version is now running?

The old Mediabot process cannot answer that reliably because it is intentionally terminated during the deployment switch.

---

🦉 After MB673

Once the updated process is really back on IRC, Mediabot now confirms the successful deployment:

Update completed. Version: 3.4dev-20260820_034834

So the complete interaction becomes:

<Te[u]K> m update now
<mediabot> Updating now...
<mediabot> updater started - progress in ...

        [silent restart behind ZNC]

<mediabot> Update completed. Version: 3.4dev-20260820_034834

The message contains the VERSION from the newly activated release, not the version known by the old process.

---

🧠 Why the confirmation comes from the new process

This is the important part of the implementation.

The process receiving m update now cannot truthfully announce:

Update completed

because it dies before the complete deployment lifecycle has finished.

Instead, MB673 splits responsibilities cleanly:

1. the old process accepts the update request;
2. the detached updater stages and activates the new tree;
3. deployment validation completes;
4. only then does the updater create a small one-shot completion marker;
5. systemd starts the new Mediabot process;
6. Mediabot reconnects to IRC;
7. when it has really rejoined the channel where the update was requested, it sends the completion message;
8. the marker is immediately consumed and deleted.

This means the success message is tied to a real successful deployment and a real IRC return.

---

🛡️ No false success after a failed update

The completion marker is created only after the updater has successfully validated the new live tree.

Therefore:

failed deployment
rollback
validation failure

cannot produce a misleading:

Update completed.

The marker also contains the expected deployed version.

At startup Mediabot compares that version with the current local VERSION file. A stale marker from an older or manually replaced deployment is discarded instead of being announced.

---

🎯 The reply returns to the right place

For an update requested from a channel:

#boulets

the restarted Mediabot waits until it has genuinely rejoined that same channel before announcing success.

There is no arbitrary:

sleep 5

or:

sleep 10

involved.

The IRC JOIN event itself is the synchronization point.

This also makes the mechanism more robust when IRC authentication, reconnect timing or channel joining takes longer than usual.

For an update requested privately, the completion is returned with a NOTICE after IRC login.

---

🔐 One-shot state

The completion state lives in:

var/update.completed.json

It is temporary operational state, not configuration.

The marker is written with restricted permissions and contains only the information required to deliver the acknowledgement:

{
  "schema": 1,
  "kind": "channel",
  "target": "#boulets",
  "version": "3.4dev-20260820_034834",
  "completed_at": 1787210755
}

After the message has been successfully emitted, the file is removed.

A runtime test confirmed this explicitly:

OK: completion marker consumed

---

🧪 Runtime validation

The complete post-restart path was exercised on the development instance.

A controlled completion marker was armed for #boulets, then Mediabot was restarted.

After the new process returned to IRC:

09:25 <@mediabotv3> Update completed. Version: 3.4dev-20260820_025922

The marker was then checked:

OK: completion marker consumed

So the test covered the actual process restart and IRC JOIN path, not only mocked unit behavior.

---

✅ Regression coverage

MB673 adds:

t/cases/858_mb673_update_completion_notice.t

and validates the existing update/systemd contracts alongside it.

Focused update regression:

PASSED : 451/451

Fast suite:

PASSED : 5299/5299  (171s)

Full suite:

PASSED : 14090/14090  (769s)

All runs completed with:

RC=0

---

📦 Files involved

MB673 changes:

Mediabot/Update.pm
install/deploy_update.sh
mediabot.pl
t/cases/858_mb673_update_completion_notice.t
VERSION

No database migration is involved.

---

⚠️ Bootstrap detail

There is one intentional transition detail.

An instance running a version older than MB673 does not yet have this completion mechanism in its updater.

Therefore, the update which first installs MB673 cannot retroactively use MB673’s new acknowledgement path.

Once MB673 or later is installed, subsequent:

m update now

operations can provide the post-restart completion message automatically.

---

🏰 Result

Self-update now has a clean end-to-end lifecycle:

requested
→ staged
→ deployed
→ validated
→ restarted
→ rejoined IRC
→ confirmed

ZNC can continue doing its job and keeping reconnect noise out of the channel.

Mediabot simply sends one useful message when everything is really finished:

Update completed. Version: <version>

The owl no longer just leaves with the package.

It comes back with the receipt. 🦉