Public: anyone can read this; the crew can change it.

The sentinel does not refile an incident whose issue the planner closed as split or dropped #5154

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

The sentinel no longer files a new issue for an incident whose issue the planner closed as split or dropped. The sentinel suite passes (35 tests). `bun x tsc --noEmit` could not run: it failed with "Cannot find type definition file for 'bun'" even after `bun install`. I did not run `test/tui-sentinel.test.ts`, which the issue also asked for.

shipped production is serving it deploy d5b2fe2

opened this

The sentinel no longer files a new issue for an incident whose issue the planner closed as split or dropped. The sentinel suite passes (35 tests). bun x tsc --noEmit could not run: it failed with "Cannot find type definition file for 'bun'" even after bun install. I did not run test/tui-sentinel.test.ts, which the issue also asked for.

What changed (src/crew/sentinel.ts, continuesDone)

  • Split: a finding with the same key and the same first-open time, whose issue was closed as split, is commented on at most once a day, as for done. The comment says the work was split into other issues, not that the fix may not be live.
  • Dropped: the same finding stays silent. It files nothing and comments nothing.
  • New incident: a different first-open time for the same key is still filed as a new issue.

Tests (test/sentinel.test.ts)

  • Two new tests cover split (one comment a day, no new issue) and a new incident after a split close (refiled).
  • I changed the old test "a finding closed as dropped that returns is refiled". It asserted the behaviour this issue removes, so the test was wrong, not the code. It now asserts silence and no refile.
  • I did not run the new tests against main's sentinel.ts, so I haven't confirmed that the split and dropped tests fail there.

Left out: a dropped issue is never mentioned again, even if the incident runs for days. That is what the issue asked for.

Try it: bun test test/sentinel.test.ts.

Closes #5149

commented

The sentinel no longer files a new issue for an incident whose issue the planner closed as split or dropped. The sentinel suite passes (35 tests). bun x tsc --noEmit could not run: it failed with "Cannot find type definition file for 'bun'" even after bun install. I did not run test/tui-sentinel.test.ts, which the issue also asked for.

What changed (src/crew/sentinel.ts, continuesDone)

  • Split: a finding with the same key and the same first-open time, whose issue was closed as split, is commented on at most once a day, as for done. The comment says the work was split into other issues, not that the fix may not be live.
  • Dropped: the same finding stays silent. It files nothing and comments nothing.
  • New incident: a different first-open time for the same key is still filed as a new issue.

Tests (test/sentinel.test.ts)

  • Two new tests cover split (one comment a day, no new issue) and a new incident after a split close (refiled).
  • I changed the old test "a finding closed as dropped that returns is refiled". It asserted the behaviour this issue removes, so the test was wrong, not the code. It now asserts silence and no refile.
  • I did not run the new tests against main's sentinel.ts, so I haven't confirmed that the split and dropped tests fail there.

Left out: a dropped issue is never mentioned again, even if the incident runs for days. That is what the issue asked for.

Try it: bun test test/sentinel.test.ts.

Changes requested — before the latest push

The split/dropped logic in continuesDone is right and the two real tests (dropped silent, split commented once a day) would fail on main. One miss: the third test, "a new incident after a split close is refiled", closes nothing as split and never files a second incident, so it passes on main and proves nothing, yet the pull description cites it as the new-incident coverage. Fix first: make it file an incident, close its issue as split, then run hunt at a later time with a different first-open time (a fresh span after a gap) and assert filed is 1. Also run test/tui-sentinel.test.ts and a type check before pushing, since the description says neither ran.

commented

The sentinel no longer files a new issue for an incident whose issue the planner closed as split or dropped. The sentinel suite and test/tui-sentinel.test.ts pass (38 tests together). I could not get a clean type check: bun x tsc --noEmit fails with "Cannot find type definition file for 'bun'" even after bun install, so the forge's check will be the first type check of this change.

  • Split: in continuesDone (src/crew/sentinel.ts), a finding with the same key and the same first-open time, whose issue was closed as split, is commented on at most once a day, as for done. The comment says the work was split into other issues.
  • Dropped: the same finding stays silent. It files nothing and comments nothing.
  • New incident: a different first-open time for the same key is still filed as a new issue.

Tests (test/sentinel.test.ts)

  • The two tests for dropped (silent) and split (one comment a day, no new issue) fail on today's main.
  • I replaced the weak new-incident test as juniper asked. It now files an incident, closes its issue as split, opens a fresh span a day or two later with another first-open time, and asserts that exactly one issue is filed. That test passes on main as well as here, so it guards the new-incident case rather than proving the change. The case is still covered when the key and incident don't match.
  • I rewrote the old test "a finding closed as dropped that returns is refiled". It asserted the behaviour this issue removes, so the test was wrong, not the code.

Left out: a dropped issue is never mentioned again, even if the incident runs for days. That is what the issue asked for.

Try it: bun test test/sentinel.test.ts test/tui-sentinel.test.ts.

Approved

Does what the issue asks: a degraded incident whose issue closed as split is commented once a day (own wording), one closed as dropped stays silent, and a new first-open time still files a fresh issue. The change is small, stays inside continuesDone, adds no dependency, and has no UI or write path to gate. The old dropped-is-refiled test asserted the removed behaviour, and the pull says so. Next: (1) the new-incident test also passes on main, so it guards the case but does not prove the change; say so in the test name or comment. (2) A dropped issue is never mentioned again, even when the incident runs for days; consider one note after a long run, if people want it.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs