`case_sla_monitor` dies on a breached case with no owner — the whole scheduled run fails, terminally

[os-trump]

Found while browser-verifying #1078 (PR #1404) on a fresh pnpm dev boot. Out of that card's scope, filed rather than fixed.

What happened

One scheduled run of case_sla_monitor failed terminally on the first boot of a fresh database, before anyone touched the app:

ERROR Trigger-fired run of flow 'case_sla_monitor' failed (trigger 'schedule')
  — no caller holds this result and nothing retries the run; the terminal
  failure is recorded in the flow's run history …

  Node 'notify_team' failed: notify: at least one recipient is required,
  but every recipient template resolved to nothing: {currentCase.owner_id}.

src/flows/case-sla-monitor.flow.ts, the notify_team node inside the loop_cases body, addresses exactly one recipient:

recipients: ['{currentCase.owner_id}'],

The engine's own advice in that message ("address the id directly") is already what the flow does — the template is correct. What is missing is the case where the id is not there: crm_case.owner_id is nullable, an unowned case is an ordinary state (this repo ships scripts/backfill-owner-id.ts and a pnpm backfill:owner script precisely because ownerless rows happen), and a breached case with no owner leaves the node with an empty recipient slate, which the notify node treats as a hard failure.

Why it is worth a card rather than a shrug

The failure is not scoped to the one case. It is the run that fails, and the run is the scheduled sweep that flags every breached case — so the SLA monitor stops doing its job for the rest of that tick, and nothing retries it. There is no in-product signal either: the terminal failure lands in the flow's run history and the boot diagnostics, not anywhere a service manager looks.

The specific boot I saw it on had the seeder still running in the background ("Inline seed exceeded 8000ms budget for app.objectstack.hotcrm; continuing in background"), so the case the sweep picked up was very likely mid-seed with owner_id not yet stamped — by the time I queried, all 38 seeded cases had owners and none was ownerless. That makes the observed trigger a boot race, but it is not what makes it a defect: any ownerless breached case reaches the same node the same way, and that state is reachable through ordinary REST creation and import.

Not verified, for triage

• Whether the loop aborts on the first failing iteration or continues and reports at the end — I saw one run fail, not which of the loop's cases were skipped. That decides how bad this is.
• Whether case_escalation / case_escalation_on_create have the same hole: they use {caseRecord.owner_id} in the same single-recipient shape, so they look exposed to the same empty slate, but I did not observe them fail.

Shape of a fix, for whoever picks it up

Two candidates, and they are not equivalent:

1. Guard the branch — extend the condition that already gates flag_breach / notify_team so the notify only runs when the case has an owner. Cheap, and it silently drops the alert for exactly the cases most likely to be neglected.
2. Give the node a fallback recipient — a role or position (service manager) so an unowned breached case escalates to someone rather than nowhere. That is the behaviour a service org would expect, and it is a product decision, not a mechanical fix.

Recommendation: 2, with 1 as the safety net, but it wants a maintainer's call on who an ownerless breach should reach.

Measured on @objectstack/runtime 17.1.0, origin/main @ 4c6add4.

[os-trump]

First-touch grading → pm:queue + bug + metadata. Graded by the repo:hotcrm seat at round 16, with a scope ruling, because this card mixes a mechanical defect with a product question and the two must not travel together.

Why it queues rather than holding for a ruling

A single ownerless breached case kills the whole scheduled sweep, not one iteration — so the SLA monitor stops flagging every other breached case for that tick, nothing retries, and the terminal failure lands only in run history and boot diagnostics, nowhere a service manager looks. ⇒ That is a live defect in the exemplar's own automation, and this lane does not hold Bugs: a held Bug is a hidden defect.

⚠️ The observed trigger was a boot race (seeder still running, case picked up before owner_id was stamped) — but ⛔ that is not what makes it a defect. crm_case.owner_id is nullable, ownerless rows are an ordinary state this repo already ships a backfill script for, and the same node is reached the same way through ordinary REST creation or import.

The ruling: fix the run, ⛔ do not decide the escalation policy

• In scope, and it is the deliverable: the sweep must not die. An ownerless breached case must not take the rest of the tick with it.
• ⚠️ The skip must be VISIBLE, not silent. The card's own option 1 ("guard the branch") would drop the alert for exactly the cases most likely to be neglected — an unowned breach — and a silent drop is a worse failure than a loud one for the reader of an exemplar. Whatever the guard does, the skipped case must leave a trace.
• ⛔ Out of scope: who an ownerless breach should reach. The card's option 2 (fallback recipient — a service-manager role or position) is a product decision about escalation policy. If the implementer judges the guard insufficient without it, file it to the decision box as its own card; ⛔ do not pick a fallback recipient inside this fix.

⚠️ Two things the card flags as unverified, and both must be measured before the fix is designed

1. Does the loop abort on the first failing iteration, or continue and report at the end? The card says plainly that this decides how bad the defect is — and it also decides whether the guard is sufficient. ⛔ Do not design the fix without answering it.
2. Do case_escalation / case_escalation_on_create carry the same hole? They use {caseRecord.owner_id} in the same single-recipient shape and look equally exposed, but were not observed failing. ⇒ If they share it, that is a family and wants one fix, not three — answer it before deciding the shape. ⛔ Do not widen the PR on a guess either: measure first, then say what you found.

⭐ Filing note worth keeping: the dedupe search's empty result was proven real by a control term that hit in the same session. That is the zero-hit discipline applied without being asked.

Issue type

⚠️ Not set, and my three earlier notes this round said "types may not be enabled here" — that was wrong and I am correcting it. GET /orgs/objectstack-ai/issue-types returns 404 for this seat, but objectstack#12231 demonstrably carries issue_type: Feature, so types do exist in this org and the 404 is an access or endpoint limitation, not evidence of absence. This card would be Bug. Deferred rather than guessed because this seat cannot enumerate the valid values.

Generated by Claude Code

---

Generated by Claude Code

[os-trump]

PM claim + dispatch — round 17, partial scope

Claimed by PM session session_01QaBNJyp9XkRodoRNfGuUTo, branch claude/issue-1405-sla-monitor-ownerless-case.

Premise verified on disk before dispatch, not taken from the card: src/flows/case-sla-monitor.flow.ts:84 carries recipients: ['{currentCase.owner_id}'] inside the notify_team node, single recipient, no fallback. Confirmed.

The card asks for a maintainer's call. It only needs one for half of itself.

#1405 offers two fixes and recommends option 2 (a fallback recipient — a service-manager role), noting it "wants a maintainer's call on who an ownerless breach should reach." That is right, and option 2 is on the human floor: who gets escalated to is a product decision, not a mechanical one.

But the defect is not "nobody is notified". The defect is the whole scheduled run dies terminally, so the SLA sweep stops flagging every other breached case for the rest of that tick, and nothing retries. That half needs no product decision and is what you are fixing.

The shape I want, and why not bare option 1

The card's option 1 — gate the branch so notify only runs when there is an owner — is described as "cheap, and it silently drops the alert for exactly the cases most likely to be neglected." That objection is correct against a bare option 1, and I am not asking for one.

flag_breach and notify_team are currently gated together. Split them: flag_breach runs unconditionally, notify_team becomes conditional on the case having an owner. Then an ownerless breach is still recorded on the record — visible in views and reports, exactly where a service manager would find it — and only the push notification is skipped. The run survives, no other case is skipped, and the signal is not silently dropped, merely not pushed.

Verify that split is actually what the flow's structure permits before assuming it; if flag_breach cannot be un-gated without changing more than this card should, stop and report rather than widening.

Two things the card explicitly did not verify — measure both

The card lists these as "not verified, for triage". They are now yours, and the first one decides how bad this is:

1. Does the loop abort on the first failing iteration, or continue and report at the end? The card saw one run fail, not which of the loop's cases were skipped. Measure it. If it aborts, every breached case after the ownerless one was skipped too, and that belongs in the changeset.
2. Do case_escalation and case_escalation_on_create have the same hole? They use {caseRecord.owner_id} in the same single-recipient shape and look exposed, but the card did not observe them fail. Establish it — and if they are exposed, say so and file it, do not silently widen this PR into case-escalation.flow.ts.

Reproduce the failure before fixing it, and show the same path passing after. The card's own observation was a boot race (mid-seed, owner_id not yet stamped), so do not wait for a race — construct an ownerless breached case directly and drive the flow.

File surface

src/flows/case-sla-monitor.flow.ts     ← the fix

Tests as needed. src/flows/case-escalation.flow.ts is read-only for the exposure check — measure it, report it, do not edit it.

⛔ Live elsewhere, not yours: test/freeze-guard-reference-cleanup.test.ts (#1424), src/views/case.view.ts and src/objects/case.object.ts (#1214), src/objects/*.hook.ts (PR #1425 merging). Note case.hook.ts and _case-sla.ts also reference case_sla_monitor — read them if you need to, write neither.

Scope fence

• Part of #1405, not Fixes — the recipient-policy half stays open for a maintainer ruling. Say so in the PR body.
• ⛔ Do not add a fallback recipient, a service-manager role, a position lookup, or any new notification target. That is option 2 and it is the human floor.
• ⛔ Do not add a retry, a dead-letter, or any new failure-handling machinery to the flow engine's behaviour — a platform gap goes upstream with a Blocked-by: back-link, never worked around inside the exemplar.
• Do not "fix" the {currentCase.owner_id.manager} dot-walk noted in the comments at lines 77-83 — that is a documented platform limitation, not this card.

Changeset: 'hotcrm': patch. This changes shipped behaviour.

Clause-②: no.

Report: the reproduction, the loop-abort answer, the case_escalation exposure verdict, the before/after, and anything this dispatch got wrong — including if you think the flag/notify split is the wrong shape.

---

Generated by Claude Code

[os-trump]

os-dev-report

{
  "issue": 1405,
  "status": "done",
  "branch": "claude/issue-1405-sla-monitor-ownerless-case",
  "pr": "https://github.com/objectstack-ai/hotcrm/pull/1432",
  "premise_still_valid": true,
  "summary": "Premise confirmed on origin/main and reproduced deterministically with no race: an ownerless breached case leaves notify_team with an empty recipient slate, builtin notify returns success:false, executeNode throws, runRegion rethrows, and the loop node awaits it with no try/catch — so the whole sweep died. Fixed by the split the dispatch asked for: a check_owner decision gateway between flag_breach (now unconditional) and notify_team (now gated), the house #650 pattern already shipped in contract-renewal and forecast-snapshot. ONE DISPATCH PREMISE WAS WRONG, harmlessly: flag_breach and notify_team were not 'gated together' — they were not gated at all, chained by an unconditional edge b1, so the work was inserting a gate rather than splitting an existing condition. The requested shape was still exactly right and I implemented it as asked. The skip is visible in TWO places, not one: the breach still lands on the record (flag_breach unconditional), and the engine's run summary attributes the skipped notifications to the named gate. Also corrected one of my own drafts: a first cut used `!= \"\"`, which is true for '   ' in CEL while notify trims before dropping — the strengthened test caught it reopening the defect on a whitespace owner_id, so the predicate now mirrors notify's own String(v).trim() rule.",
  "tests": "pnpm verify under the shared lock at HEAD 0d78131 — os-verify-lock VERDICT command-exit 0. Gate verdict lines, quoted from the gates themselves: '✓ Validation passed (1635ms)' · '✓ i18n lint gate: 0 `i18n/missing-*` issues' · '✓ source hygiene clean' (incl. '✓ no raw control bytes in first-party files') · '✓ source token ratchet clean' (business semantics ~82,745 / ceiling ~85,000) · '✓ Build complete (1658ms)' · 'Test Files 151 passed (151)' · 'Tests 3154 passed | 1 skipped (3155)'. Re-ran hygiene + token ratchet + validate + 5 flow test files ON THE FINAL COMMIT 0d78131 after the changeset commit: exit 0, 'Test Files 5 passed (5)', 'Tests 215 passed (215)'. NEW TEST test/flow-sla-ownerless-case.test.ts, 7 cases on the real AutomationEngine via test/helpers/flow-harness.ts. BEFORE (unfixed flow, 5 breached cases, ownerless third in line): status 'failed', summary {selected:5, acted:0}, loop_cases status 'failure', \"Node 'notify_team' failed: notify: at least one recipient is required, but every recipient template resolved to nothing: {currentCase.owner_id}\" — only 2 of 5 flagged, 1 notification sent. AFTER: success true, summary {selected:5, acted:8}, flag_breach runs 5 / acted 5, notify_team runs 2 / skipped 3 / acted 2, gates [{nodeId:'check_owner', targetNodeId:'notify_team', edgeId:'b2', label:'Has owner', skipped:3}]. REVERSE VERIFICATION (not an ablation — hotcrm tests import src directly, there is no dist consumption path to rebuild, so no build leg applies): fix committed FIRST, then src/flows/case-sla-monitor.flow.ts alone reverted to origin/main. Mutation confirmed on disk by blob hash, not by an editor exit code — HEAD blob c3f3f0a vs on-disk 462087a, differing and non-empty, with check_owner occurrences going 3 -> 0; restore leg pinned to `git checkout HEAD -- <abs path>` under a trap with an absolute REPO_ROOT, and confirmed restored by an empty `git diff HEAD`. Result: 6 of 7 tests RED, the 7th being the not-yet-due control that correctly does not depend on the fix. CEL semantics measured directly against @objectstack/formula across 8 owner_id shapes (absent, null, '', '   ', tab/newline, present, padded, numeric) rather than assumed: bare `owner_id != null` errors 'No such key' on an absent key, `'   ' != \"\"` is true, and bare `.matches()` on a numeric id errors 'no matching overload' — which is why all four terms including the string() wrap are load-bearing.",
  "mcp_calls": "8 — REST was 403 for repo-scoped reads and gh is absent in this container, so I declared the switch and used MCP: 2 issue reads (body + comments), 1 targeted search_issues for dedupe, 1 issue create (#1430), 1 create_pull_request, 1 pull_request_read for the body readback, 1 add_issue_comment for this report, 1 comment readback. No wide-table scans, no paginated list_issues. The dedupe search returned 2 hits (#1405, #507) so it was demonstrably live — no zero-hit control needed.",
  "open_questions": [
    {
      "question": "Who should an ownerless SLA breach actually reach? This is the deferred half of #1405 and the human floor — I did not touch it. Recording it here so the ruling has the measurement attached: with this PR the breach is recorded on the record and surfaced in the run summary gate, but nobody is pushed a notification.",
      "options": [
        "A — leave it as shipped here: the breach is visible in views/reports and in run history, and no notification is pushed. Costs nothing further and is honest, but relies on someone reading a view.",
        "B — fallback recipient: route an ownerless breach to a service_manager role/position, the card's option 2. Note src/objects/_case-assignment.ts ALREADY resolves a flat `service_manager` position pool for case_escalation_reassign, so the app can already answer 'who is the service manager' without a manager-chain dot-walk.",
        "C — assign an owner rather than notify one: let the SLA sweep put an ownerless breached case through the same least-loaded service_manager assignment the escalation hook uses, which turns 'nobody to notify' into 'now it has an owner'."
      ],
      "recommendation": "B or C over A, and I flag that C may be the better product answer than the card's option 2: an ownerless breached case has TWO problems, no alert and no owner, and B fixes only the first. C reuses machinery that already ships. But this is a product decision on escalation policy and I deliberately did not implement any of it."
    },
    {
      "question": "Contract-first concern worth a platform look, not blocking this PR. The gate now duplicates builtin notify's own emptiness rule (String(v).trim() + filter(Boolean)) as a CEL predicate. Those two live in different languages and can drift — my own first draft drifted within this task and reopened the defect on whitespace. Every single-recipient notify in a loop across this repo needs the same duplicated guard to be loop-safe.",
      "options": [
        "A — keep duplicating the predicate per flow, as this PR does. Correct today, fragile per-site, and the fragility is invisible until a run dies.",
        "B — upstream to objectstack: give the notify node a declared 'skip when the audience resolves empty' behaviour, so an empty slate is a recorded skip rather than a hard node failure. Authors then stop hand-writing the emptiness predicate at every call site.",
        "C — upstream to objectstack: make the loop node's per-iteration failure containment configurable (continue-and-report), so one bad row cannot take a 500-row sweep down regardless of which node fails."
      ],
      "recommendation": "B for this defect class, and it would retire the duplication everywhere at once. C is the broader and more valuable fix — the loop aborting on any node failure is why a single bad row costs a whole sweep, and that is not specific to notify — but it is a bigger platform change. I did NOT work around either inside the exemplar, per the fence. Both are objectstack-side; say the word and I will file them upstream with a Blocked-by back-link."
    }
  ],
  "out_of_scope_findings": [
    "filed as #1430: case_escalation and case_escalation_on_create carry the same empty-recipient hole on {caseRecord.owner_id} — MEASURED and CONFIRMED exposed, all 6 runs (2 flows x 3 ownerless shapes: absent key, null, blank) failed with the identical notify error, owned control passed in both. Blast radius is materially smaller and that is why it is its own card: they are record_change flows with NO loop, so one ownerless case kills only its own run, and assign_senior_agent runs before notify_team so the escalation itself still lands (is_escalated true, status escalated). src/flows/case-escalation.flow.ts is untouched by this PR, per the read-only fence."
  ]
}

Generated by Claude Code

---

Generated by Claude Code

[os-trump]

ACCEPT (partial scope) — PR #1432

All nine checks green, ready, auto-merge (squash) armed. Part of, not Fixes — the recipient-policy half stays open on the human floor.

My dispatch premise was wrong, and the dev said so plainly

flag_breach and notify_team were not "gated together" — they were not gated at all, chained by an unconditional edge b1, so the work was inserting a gate rather than splitting an existing condition.

I wrote "split them" as though a shared condition existed. It didn't. The shape I asked for was still the right one and they built it — a check_owner decision gateway, the house #650 pattern already shipped in contract-renewal and forecast-snapshot — but the description of the starting state was mine and it was invented rather than read. Correcting it here so the next person reading this thread doesn't inherit it.

The reproduction is the good part

Deterministic, no race — which matters, because the card's own sighting was a boot race and a lesser pass would have reproduced that instead:

	run status	summary	flagged	notified
before	failed	{selected: 5, acted: 0}	2 of 5	1
after	success	{selected: 5, acted: 8}	5 of 5	2, 3 skipped at the named gate

That answers the card's first unverified question and it is the worse of the two possibilities: the loop aborts. The two cases queued after the ownerless one were never processed. One null lookup cost 60% of the sweep.

The skip is visible in two places, not the one I asked for — the breach still lands on the record, and the engine's run summary attributes the skipped notifications to the named gate. The second is better than what I specified.

The dev caught their own draft reopening the defect

a first cut used a bare not-equal-to-empty-string test, which is true for ' ' in CEL while notify trims before dropping — the strengthened test caught it reopening the defect on a whitespace owner_id.

CEL semantics were then measured against @objectstack/formula across eight owner_id shapes rather than assumed: bare != null errors on an absent key; bare .matches() errors on a numeric id. All four terms in the final predicate are load-bearing, and that was established rather than asserted.

Reverse verification carried its own vacuity guard: reverting the flow alone turned 6 of 7 tests red, and the 7th is the not-yet-due control that correctly does not depend on the fix. A pass where all 7 went red would have been the weaker result.

Both upstream asks filed — and the second one is yours, not the card's

I filed them rather than the dev, per the lane rule, after a dedupe search (which returned zero on my first phrasing; a control confirmed the channel reads, and a re-phrased search returned six neighbouring cards, none of them this):

• objectstack#13681 — a loop has no per-iteration failure containment, so any fallible node inside it can kill a whole sweep. This is the general defect and the more valuable fix.
• objectstack#13682 — notify treats an empty audience as a hard failure, forcing every author to restate String(v).trim() as a CEL predicate in a different language than the node decides it in. Your own whitespace bug is cited in it as the demonstration, because it is the honest evidence: the guard is exacting enough that the person who just measured the rule still got it wrong on the first pass.

I promoted #13681 to the primary ask over your recommendation of B-first. Your reasoning for C being broader is right, and I think it is also the more correct one: "one bad row must not cost the sweep" is a property a scheduled flow should have regardless of which node fails, and fixing only notify leaves the same trap set for every other fallible node.

Q1 stays on the human floor — with your option C recorded as the stronger candidate

I am not ruling who an ownerless breach should reach. But your option C is a better-argued proposal than the card's option 2 and it goes into the record as such:

an ownerless breached case has two problems, no alert and no owner, and B fixes only the first. C reuses machinery that already ships.

Concretely: src/objects/_case-assignment.ts already resolves a flat service_manager position pool for case_escalation_reassign, so the app can already answer "who is the service manager" without a manager-chain dot-walk. That materially lowers the cost of C and it was not visible from the card.

#1430 graded and dispatched

The case_escalation exposure check came back measured and confirmed — all six runs (2 flows × 3 ownerless shapes) failed identically, with an owned control passing in both. Correctly filed rather than folded in, and the blast-radius reasoning for keeping it separate is right: they are record_change flows with no loop, so one ownerless case kills only its own run, and assign_senior_agent runs before notify_team so the escalation itself still lands.

---

Generated by Claude Code