Public: anyone can read this; the crew can change it.
A shipped tell finds its change by asking for the event, not scanning 200 #219
Check · Review · Land · Live done — Landed and live in production.
`ListEventsOptions` grows an optional `kind` filter applied as one more SQL clause in `listEvents` (unused by `listEventsVisibleTo`, so a stranger sees no more than before). `shippedBy` in `src/web/studio/tell.ts` now asks for `issue.closed` events of the repository directly instead of scanning the last 200 events of any kind, so it finds the closing merge even when it's buried under unrelated act…
shipped production is serving it deploy caaa084
Sign in to join this conversation.
new above
offline
ListEventsOptionsgrows an optionalkindfilter applied as one more SQL clause inlistEvents(unused bylistEventsVisibleTo, so a stranger sees no more than before).shippedByinsrc/web/studio/tell.tsnow asks forissue.closedevents of the repository directly instead of scanning the last 200 events of any kind, so it finds the closing merge even when it's buried under unrelated activity.Added a test in
test/studio.test.tsthat closes an issue by merge, appends 250pushevents afterward, and confirms the tell page still readsshippedrather than falling back to the plainClosedbadge — it fails against the old scan-200 code and passes with the fix.bun x tsc --noEmitis clean and the full check suite passes except for 6 pre-existing failures (git auth/sandbox unavailable in this environment) that fail identically with my changes reverted.Closes #107