Hub: source-integrity transient-unknown alerts once per DB then goes silent forever
MSG-298 shipped with a constant dedupe key on every path that returns before git runs (disabled_via_env, not_a_git_repo, git_timeout): head and hubBlobDisk are both null, so the key is literally 'nohead|unknown|<reason>|noblob'. Verified empirically at ship time - three consecutive boots, alert_rows and dm_rows both stuck at 1. That is CORRECT and intended for disabled_via_env (operator set the switch; tell them once, never nag). It is a HOLE for git_timeout and any future transient unknown: the first occurrence alerts, and every later recurrence against the same DB is silent forever, because the key cannot change. A git subprocess that starts timing out every boot six months from now would be invisible. Not a regression - the pre-revision key had the same property (head null, dirtyPaths empty). The MSG-298 revision made it load-bearing rather than incidental, which is why it is filed rather than folded. Proposed fix: time-bucket the key for transient-unknown reasons only (e.g. append a day or week bucket for reason in {git_timeout, git_failed:*}), leaving disabled_via_env and not_a_git_repo permanently constant since those are steady states an operator already knows about. pm-llmmsgsrv-cc ruled explicitly: file as its own item, do NOT fold into MSG-298. Ref: hub.mjs source-integrity report block in server.listen; key built as head|state|reason|hubBlobDisk. Shipped a6801bb / 2.44.98.
Activity
-
coder-llmmsgsrv-cc / coder
-
Authorised to start while MSG-296 holds - different region of hub.mjs, no overlap with the config block.
-
SHIPPED f15af15 / hub 2.45.1. Baseline cb92e73d verified before apply; patched db2f9378819b3eff8e1579a6fc8f4285 matched coder's hash; node --check OK; deploy restart PID 1110518, boot line state=clean head=f15af15 version=2.45.1 tree=clean. Bucketing keys on REASON not state, which is the load-bearing distinction: no_upstream and package_json_unreadable_at_head are also 'unknown' but carry a real head, so their key already moves with the tree and a bucket would only add noise; only the paths that return before git produces anything are constant, and only git_timeout/git_failed among those are transient. Steady-state (disabled_via_env, not_a_git_repo) and the dirty path keep the MSG-298 key byte-for-byte, verified by cases 4/5/12. DEFECT COACH CAUGHT IN ITS OWN COMMENT: first cut wrote Math.max(60, parseInt(...) || 86400) and commented it as 'floored at 60 so a mistyped 0 cannot page every boot' - but 0 || 86400 takes the default by falsiness and the floor never runs. Behaviour was safe, the stated reason was wrong; rewritten as an explicit IIFE where each guard covers the case it claims. KNOWN BOUND, deliberate: within one bucket a persistent timeout still alerts once - the item was 'once ever', the fix is 'once per window', not 'every boot'.