Owner notices report four conditions; the ask is "any error event on the server" #179

New Issue

2026-09-23T08:55:40+07:00

sulthan commented

2026-09-23 08:55:40 +07:00

This was generated by AI during triage.

Split out of #178, which reported two things at once: a webhook that stayed silent
while the browser was unreachable (the bug, tracked on #178) and a scope request —
"I want the discord bot to be as informative as they can. Reporting any error event
that are happening in the server." This ticket is only the second half.

The request

Today the outbound path (internal/notify, latest.FaultsFrom) judges exactly four
conditions — ConditionStall, ConditionNoBrowserRoute, ConditionSidecarDown,
ConditionAdapterBroken — and each fires once per episode. Everything else that goes
wrong on the server is a log.Printf line and nothing more: a failed cover
acquisition, a failed store write inside a pass, a refused Site with a browser route,
a 500 from a handler, and — notably — a failed owner-notice POST itself.

Why this is not a straight yes

#137 chose the four conditions with a stated rule, and the rule is the decision, not
the list: a fault reaches the owner only when it is silent on every Reader surface,
wrong, repairable only by the owner, and persisting past twelve hours
(latest.OwnerWindow). "Any error event" inverts that rule — most server errors are
either visible within one reading session (the web UI dies visibly, the userscript
degrades to its cache), self-healing by the next pass, or so frequent that a channel
full of them trains the owner to ignore the one message that mattered.

So this needs grilling before it can be built. The shape it most plausibly collapses
to, and the part that #178 actually exposes:

The notice path cannot report on itself. A failed POST is logged and the
suppression row left unwritten (Poller.ownerNotices); a webhook that is unset,
revoked or unreachable produces exactly the same observable as a healthy server with
nothing to say — silence. That is the same silent-fault class the whole feature was
built to kill, and it is the one error event that cannot be delivered by the channel
it concerns.
Candidate answers to grill: surface notice configuration and the last send outcome
on the Lanes page beside the poller/browser facts; a startup or manual test ping; a
fifth condition for a class the four miss; a severity split. Or: reject the general
form and keep the rule.

Open questions for triage

Which concrete event did you actually miss, besides the one on #178? A list of real
misses is what tells us whether this is a fifth condition or a diagnosability gap.
Should the channel carry anything that is not a fault by the #137 rule — a
heartbeat, a deploy note, a daily digest? That is a different decision from widening
the fault set, and it is the one that decides whether the four-test rule survives.
If a message can arrive more than once per episode, what stops the channel becoming
a log tail?

> *This was generated by AI during triage.* Split out of #178, which reported two things at once: a webhook that stayed silent while the browser was unreachable (the bug, tracked on #178) and a scope request — *"I want the discord bot to be as informative as they can. Reporting any error event that are happening in the server."* This ticket is only the second half. ## The request Today the outbound path (`internal/notify`, `latest.FaultsFrom`) judges exactly four conditions — `ConditionStall`, `ConditionNoBrowserRoute`, `ConditionSidecarDown`, `ConditionAdapterBroken` — and each fires once per episode. Everything else that goes wrong on the server is a `log.Printf` line and nothing more: a failed cover acquisition, a failed store write inside a pass, a refused Site with a browser route, a 500 from a handler, and — notably — a failed owner-notice POST itself. ## Why this is not a straight yes #137 chose the four conditions with a stated rule, and the rule is the decision, not the list: a fault reaches the owner only when it is **silent on every Reader surface**, **wrong**, **repairable only by the owner**, and **persisting past twelve hours** (`latest.OwnerWindow`). "Any error event" inverts that rule — most server errors are either visible within one reading session (the web UI dies visibly, the userscript degrades to its cache), self-healing by the next pass, or so frequent that a channel full of them trains the owner to ignore the one message that mattered. So this needs grilling before it can be built. The shape it most plausibly collapses to, and the part that #178 actually exposes: - **The notice path cannot report on itself.** A failed POST is logged and the suppression row left unwritten (`Poller.ownerNotices`); a webhook that is unset, revoked or unreachable produces exactly the same observable as a healthy server with nothing to say — silence. That is the same silent-fault class the whole feature was built to kill, and it is the one error event that cannot be delivered by the channel it concerns. - Candidate answers to grill: surface notice configuration and the last send outcome on the Lanes page beside the poller/browser facts; a startup or manual test ping; a fifth condition for a class the four miss; a severity split. Or: reject the general form and keep the rule. ## Open questions for triage - Which concrete event did you actually miss, besides the one on #178? A list of real misses is what tells us whether this is a fifth condition or a diagnosability gap. - Should the channel carry anything that is *not* a fault by the #137 rule — a heartbeat, a deploy note, a daily digest? That is a different decision from widening the fault set, and it is the one that decides whether the four-test rule survives. - If a message can arrive more than once per episode, what stops the channel becoming a log tail? ## Related - #178 — the bug this was split from - #137 — the spec that set the selection rule - #171, #172 — the path and its four conditions

sulthan added the enhancement needs-triage labels 2026-09-23 08:55:46 +07:00

sulthan referenced this issue

2026-09-23 08:56:07 +07:00

Discord webhook doesnt work #178

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sulthan/mangaBookmark#179