[bug] dsh-superagent: GitHub Source silently drops a mention when its notification arrives late (race with the poll cursor)

[grep-uoffer]

This is about dsh-superagent-prototype, which has Issues turned off, so I am reporting it here.

Summary

When GitHub delivers the agent account's notification later than the start of the next polling round, the GitHub Source reads the notified Issue but treats its body (and comments) as older than the cursor. The request is dropped without a Trigger. It is not counted as filtered, and the Source health stays ready.

With the default 60 s poll and the notification delay we observed (about 23 s), roughly one in three requests can be lost this way.

Observed

A fresh setup, with the agent account mentioned in the body of a new Issue by an allowed login:

Time (UTC)	Event
05:44:57	Issue created (created_at) with @<agent> … in the body
~05:45:13	A round starts, sees no notification yet, and stores github-since ≈ 05:45:08 (cursorAt(round.started))
05:45:20	GitHub's mention notification appears (updated_at), 23 s after the Issue
05:46:13	The next round reads the notification and issues/1 (github-cursor:1 is written), but no Trigger is stored

After 30 minutes: GET tickets, GET decisions and GET threads were empty, and GET sources showed stats.received: 0, filtered: []. The notification was still unread in the agent account.

Cause

In readNotified (src/sources/github.ts), since is the notification cursor:

const opened = Date.parse(issue.created_at) >= Date.parse(since) && !sameName(issue.user.login, login)

issue.created_at (05:44:57) is earlier than the cursor (05:45:08), because the cursor moved during the notification's delivery delay. The body is skipped as if the Issue were old. The PR description check, and the timestamp < since filter in intakeComments, have the same race for a PR or a comment.

Fix

Read back a fixed lag before the cursor in readNotified, and rely on the existing Trigger ID deduplication (github-issue:<number>, github-comment:<url>:<id>:<updated_at>, and Intake answers duplicate):

/** How long GitHub may take to deliver a notification after the activity it reports. */
export const NOTIFICATION_LAG_MS = 5 * 60_000

async function readNotified(ctx: SourceContext, round: Round, number: number, item: Retry): Promise<void> {
  // A notification can appear well after the Issue, PR or comment it is about, so a round may have moved the cursor past
  // its timestamp already; read back NOTIFICATION_LAG_MS before the cursor, relying on Trigger ID deduplication.
  const since = new Date(Date.parse(item.since) - NOTIFICATION_LAG_MS).toISOString()

The stored cursors are unchanged; only the comparison and the comments query start earlier. Repository streams and subscribed Thread polling are not affected.

The patch at the end of this post also:

• adds a regression test: a PR opened 30 s before the cursor whose notification arrives late is taken in;
• updates the one test that asserted the exact comments since query.

Verification

• pnpm typecheck passes. pnpm build passes.
• pnpm test: 1197 of 1198 pass. The one failure exists without this patch: tests/sources.spec.ts > feishu event consumer > … reports a malformed line without stopping fails consistently on this machine (health ends ready rather than error, likely stderr [event] ready arriving after the malformed stdout line).
• End to end, after the patch: a new comment mentioning the agent became a Ticket within about a minute, and the agent opened a PR and replied in the thread.

Environment

• dsh-superagent main as of 2026-10-31, version 0.1.0
• @deepseek-ai/dsh 0.2.1-rc.3
• Ubuntu 24.04 on WSL2, Node.js 22.22.0, pnpm 11.7.0, gh 2.103.3

Smaller note

The first acknowledgement comment did not begin with the GitHub disclosure line from the Communication prompt ("This is by an automated agent, not a human."). The later result comment and the PR description did.

Patch

notification-lag.patch

diff -ru a/src/sources/github.ts b/src/sources/github.ts
--- a/src/sources/github.ts	2026-11-02 22:25:02.284515689 -0800
+++ b/src/sources/github.ts	2026-11-02 22:25:02.284515689 -0800
@@ -154,6 +154,8 @@
 const stopped = (ctx: SourceContext, round: Round): boolean => !!round.signal?.aborted || !ctx.config(SOURCE)
 export interface Retry { since: string; pr: boolean; failedAt?: string; attempts?: number }
 const RETRY_WINDOW_MS = 24 * 3600_000
+/** How long GitHub may take to deliver a notification after the activity it reports. */
+export const NOTIFICATION_LAG_MS = 5 * 60_000
 /** True when GitHub returns HTTP 410 (Gone); HTTP 404 is retried because it can indicate revoked access to a private repository. */
 const deleted = (error: unknown): boolean => error instanceof CliError && error.code === 410
 /** Records a failed read on the Thread and in the round; deleted (410) or abandoned (24h+) threads do not fail the round. */
@@ -342,7 +344,9 @@
   return { count: notifications.length, interval }
 }
 async function readNotified(ctx: SourceContext, round: Round, number: number, item: Retry): Promise<void> {
-  const { since } = item
+  // A notification can appear well after the Issue, PR or comment it is about, so a round may have moved the cursor past
+  // its timestamp already; read back NOTIFICATION_LAG_MS before the cursor, relying on Trigger ID deduplication.
+  const since = new Date(Date.parse(item.since) - NOTIFICATION_LAG_MS).toISOString()
   let isPr = item.pr
   if (!isPr) {
     const issue = await ctx.commands.withSignal(round.signal).api(IssueSchema, `issues/${number}`)
diff -ru a/tests/sources.spec.ts b/tests/sources.spec.ts
--- a/tests/sources.spec.ts	2026-11-02 22:25:02.284515689 -0800
+++ b/tests/sources.spec.ts	2026-11-02 22:25:02.284515689 -0800
@@ -714,6 +714,17 @@
     expect(h.receive.mock.calls.filter(([trigger]) => trigger.meta.kind === 'pull')).toEqual([])
     h.store.close()
   })
+  it('takes in a description whose notification arrived after a round had moved the cursor past it', async () => {
+    const h = host()
+    // The PR was opened 30s before the cursor: a round ran while GitHub had not delivered its notification yet.
+    h.store.set('github-since', '2026-09-09T00:00:30.000Z')
+    const pr = { ...openPull(9), body: '@agent-bot please review', created_at: '2026-09-09T00:00:00Z' }
+    github(h, { notifications: [{ ...notification(9, 'pulls'), updated_at: '2026-09-09T00:00:40Z' }], 'pulls/9': pr })
+    await pollRound(h)
+    const id = issueTrigger({ ...pr, id: 9 } as GithubIssue, 'agent-bot').id
+    expect(h.receive.mock.calls.map(([trigger]) => trigger.id)).toContain(id)
+    h.store.close()
+  })
   it('reads a subscribed default-branch CI Thread as no Issue, and keeps no poll error on it', async () => {
     const h = host()
     h.store.tickets.save(openTicket('ticket'))
@@ -858,8 +869,8 @@
     await pollRound(h)
     const expected = commentTrigger(comment, { number: 12, isPr: false, url }, 'conversation', 'agent-bot')
     expect(h.receive.mock.calls.map(([trigger]) => trigger)).toEqual([expected])
-    // An Issue has only its conversation; the comments are read since the notification cursor.
-    const since = encodeURIComponent('2026-09-08T00:00:00.000Z')
+    // An Issue has only its conversation; the comments are read from NOTIFICATION_LAG_MS before the notification cursor.
+    const since = encodeURIComponent('2026-09-07T23:55:00.000Z')
     expect(reads.filter(path => path.includes('/comments'))).toEqual([`issues/12/comments?per_page=100&since=${since}`])
     h.store.close()
   })

[13673625414jcy-coder]

I reproduced the comment case with a local Vitest fixture on dsh-superagent-prototype commit 8c32a9d (macOS arm64, Node.js 25.4.0). The fixture uses an existing Issue, an allowlisted sender, and observe mode. In both runs, the poll reads one mention notification with updated_at=06:01:10Z and queries the Issue's comments with since=06:00:55Z.

Comment updated_at (UTC)	Explicit candidates	Tickets	POSTs to the original Issue
06:00:58Z	1	1	2 (acknowledgement and result)
06:00:50Z	0	0	0

In the second run, the Issue cursor advanced to 06:01:55Z and the GitHub Source still reported ready. The expected behavior is one explicit candidate in both runs because the notification was received and the sender was allowed. GitHub responses and model actions were simulated in both runs.

[chaos-xxl]

Independent reproduction on 8c32a9d (current main after the 11-03 force-push): macOS arm64, Node 24.13.0, DSH 0.2.1-rc.3, GitHub Source on a private scratch repository, default 60 s poll.

Burst case. Five new Issues, each mentioning the agent in its body, were opened within 6 s (created_at 09:52:01–09:52:07Z). Their mention notifications appeared about 22 s later (updated_at 09:52:23–30Z). The next round read all five Issues and wrote github-cursor:3..7 = 09:53:14.951Z, but stored no Trigger: the Source still showed received: 1 (an earlier smoke test), and the trigger table held only that row. After 3 minutes there were no acknowledgements and no Workers.

So a burst that lands in the window before a poll starts is lost as a whole, not one request in three. That is the case Super-agent is built for: several requests at once.

Workaround that recovered all five. Wait until github-since changes (a round has just ended), then add one comment with the mention to each Issue. All five were acknowledged about 83 s later and finished in parallel.

From the code, the read-back fix in the original post covers this case. I have not run the patch.