Issue 384 (note 17): at 09:18 the desk's store answered 'no responders' while the urgent 'A new build of mesh-controller cannot be delivered' was shown; the desk could not keep where it showed it, so the router's clearing at 09:34 found no record and was shown as a new notification beside the urgent one, which stayed on the operator's screen for hours. The same happened at 23:50, 00:49, 01:25 and 08:48, each during a bus outage.
Now what was shown is held in memory when the store does not answer and recalled first by edits, reminders, clicks and a notifier start; it is kept in the store at the start of the next work and in the existing minute loop (no new timer), stopping at the first unanswered write; the work is always taken (no redelivery, so a raise can never come back over its clearing). A desk restarted during an outage loses where those messages are shown, and its log says how many.
Tests: subtests 'store still down' and 'store back' (the clearing replaces notification 1 in place; screen, memory and, when back, store end on the clearing). Full try try-1793011832017025140 passed. Reviewed in two rounds (round 1 found a redelivered raise could replace its clearing). A rare stale store write is noted on issue 384.
Issue 384 (note 17): at 09:18 the desk's store answered 'no responders' while the urgent 'A new build of mesh-controller cannot be delivered' was shown; the desk could not keep where it showed it, so the router's clearing at 09:34 found no record and was shown as a new notification beside the urgent one, which stayed on the operator's screen for hours. The same happened at 23:50, 00:49, 01:25 and 08:48, each during a bus outage.
Now what was shown is held in memory when the store does not answer and recalled first by edits, reminders, clicks and a notifier start; it is kept in the store at the start of the next work and in the existing minute loop (no new timer), stopping at the first unanswered write; the work is always taken (no redelivery, so a raise can never come back over its clearing). A desk restarted during an outage loses where those messages are shown, and its log says how many.
Tests: subtests 'store still down' and 'store back' (the clearing replaces notification 1 in place; screen, memory and, when back, store end on the clearing). Full try try-1793011832017025140 passed. Reviewed in two rounds (round 1 found a redelivered raise could replace its clearing). A rare stale store write is noted on issue 384.
Reviewed-by: review-desk@shanks at a30c1685124656699dced991b3099589011f18db
On 2026-10-26 09:18 the bus reloading its accounts made the desk's state store answer
'no responders' just as the urgent 'A new build of mesh-controller cannot be delivered'
was shown. The desk logged that it could not keep the notification ids and acked the work;
the router's clearing at 09:34 then found no record, was shown as a new notification, and
the urgent one stayed on the operator's screen for hours.
Now what was shown and not kept is held in memory, recalled before the store by edits,
reminders, clicks and a notifier restart, kept at the next piece of work, and its work is
offered again until the store keeps it, without being shown twice. An edit of a message
nothing records is said in the journal.
Review round 1: offering the work again let a redelivered raise follow its own clearing and
replace it, and a redelivery is bounded where an outage is not. The work is now taken; what
was shown stays in memory, recalled first, and is kept at the start of the next work and at
the minute's standing, stopping at the first write the store does not answer. A desk that
restarts before then loses where those are shown, and its log said how many it held.
Deliverynovox/mesh-catalog@a30c16851246 — merged since 2026-10-26T11:33:48Z
Source — source.main moved to novox/mesh-catalog@86fdf74a0a. Whether it reached the machines is mesh-delivery-view's, derived from source.main, the wants and the haves.
Transitions
2026-10-26 11:10 (new) → proposed (announced): novox/mesh-catalog#490's head announced
2026-10-26 11:10 proposed → ready (accepted): a verdict names this commit and the trunk's head as its trunk commit, the gate passed or warned, and the repository's own check did not fail; or the check gates no merge (check-gates-merge false)
2026-10-26 11:33 ready → merged (merged): on the trunk its modules follow: merged there
The commit's note under refs/notes/mesh-plan keeps every transition of this change up to its merge: git log --notes=mesh-plan.
<!-- mesh-delivery:view -->
**Delivery** `novox/mesh-catalog@a30c16851246` — **merged** since 2026-10-26T11:33:48Z
**Source** — source.main moved to novox/mesh-catalog@86fdf74a0a83. Whether it reached the machines is `mesh-delivery-view`'s, derived from `source.main`, the wants and the haves.
**Transitions**
- 2026-10-26 11:10 (new) → proposed (announced): novox/mesh-catalog#490's head announced
- 2026-10-26 11:10 proposed → ready (accepted): a verdict names this commit and the trunk's head as its trunk commit, the gate passed or warned, and the repository's own check did not fail; or the check gates no merge (check-gates-merge false)
- 2026-10-26 11:33 ready → merged (merged): on the trunk its modules follow: merged there
The commit's note under `refs/notes/mesh-plan` keeps every transition of this change up to its merge: `git log --notes=mesh-plan`.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Issue 384 (note 17): at 09:18 the desk's store answered 'no responders' while the urgent 'A new build of mesh-controller cannot be delivered' was shown; the desk could not keep where it showed it, so the router's clearing at 09:34 found no record and was shown as a new notification beside the urgent one, which stayed on the operator's screen for hours. The same happened at 23:50, 00:49, 01:25 and 08:48, each during a bus outage.
Now what was shown is held in memory when the store does not answer and recalled first by edits, reminders, clicks and a notifier start; it is kept in the store at the start of the next work and in the existing minute loop (no new timer), stopping at the first unanswered write; the work is always taken (no redelivery, so a raise can never come back over its clearing). A desk restarted during an outage loses where those messages are shown, and its log says how many.
Tests: subtests 'store still down' and 'store back' (the clearing replaces notification 1 in place; screen, memory and, when back, store end on the clearing). Full try try-1793011832017025140 passed. Reviewed in two rounds (round 1 found a redelivered raise could replace its clearing). A rare stale store write is noted on issue 384.
Reviewed-by: review-desk@shanks at
a30c168512Delivery
novox/mesh-catalog@a30c16851246— merged since 2026-10-26T11:33:48ZSource — source.main moved to novox/mesh-catalog@86fdf74a0a. Whether it reached the machines is
mesh-delivery-view's, derived fromsource.main, the wants and the haves.Transitions
The commit's note under
refs/notes/mesh-plankeeps every transition of this change up to its merge:git log --notes=mesh-plan.