fix(linear): one nested GraphQL query per batch + re-establish sync-completion signal by KrisBraun · Pull Request #213 · plotday/plot

KrisBraun · 2026-06-20T17:55:36Z

Why

Two distinct production failures on the Linear connector, both surfacing as a stuck/looping connection.

1. DO-storage-timeout stuck sync (the GraphQL rewrite)

syncBatch pulled 50 issues/batch and the old convertIssueToLink lazy-loaded each issue's creator/assignee/state/comments/attachments (and each comment's user) through the Linear SDK — every relation is a separate GraphQL round-trip, ~250+ sequential calls per execution. When Linear degraded (502s), an execution stretched long enough to exceed the per-tool Storage Durable Object timeout → DO reset. That error isn't transient-classified, so the run-queue retried — but the pagination cursor only advances at the end of syncBatch, so the retry re-ran the same batch forever (stuck "Syncing").

Fix: one nested GraphQL query per page (TEAM_ISSUES_BATCH_QUERY in the new linear-sync.ts) replaces all the lazy-loads. ISSUES_PER_PAGE=25 (≈2,500 complexity pts, 4× under Linear's 10k cap). Pure buildIssueLink / resolveAuthorContact (unit-tested). A 502 now throws once and retries a single cheap query instead of fanning out per field.

2. Endless "Reconnect" loop (re-establish `channelSyncCompleted`)

The connector's syncBatch finished the final page by just clearing sync state — it never called channelSyncCompleted, so the runtime never stamped initial_sync_completed_at. The connection sat in "Syncing" until the stuck-sync watchdog (recover-stuck-syncs.ts, MAX_INITIAL_SYNC_ATTEMPTS=3) gave up and flipped it to "Reconnect" — then each reconnect restarted the loop (~hourly). Confirmed in prod against a real account: current Linear connection had initial_sync_attempts=3, initial_sync_completed_at=NULL, needs_reauth_at set, while the connector was otherwise healthy (data flowing, zero sync errors in error-tracking).

#212 already landed this signal on main in the oldsyncBatch; this branch forked before that and rewrote the whole method, so the call had to be re-established in the new terminal branch (gated on state.initialSync, matching #212). Merged main in so the branch carries both.

Tests

New linear.test.ts (slack.test.ts-style in-memory store + mocked tool-shed): signals channelSyncCompleted once on the final page; stays quiet while more pages remain.
linear-sync.test.ts (8) covers buildIssueLink / resolveAuthorContact.
pnpm test (10/10), pnpm build (tsc), plot lint all green.

No changeset (connector-only change). Backwards-compatible: source, callback signatures, and SyncState shape unchanged.

🤖 Generated with Claude Code

syncBatch lazy-loaded each issue's creator, assignee, state, comments, and attachments through the Linear SDK — every relation is a separate GraphQL round-trip, so a 50-issue batch fired 250+ sequential calls in a single execution. When Linear was degraded (the GraphQL 502s in the logs), that execution stretched long enough for a Storage Durable Object operation to exceed its timeout and reset the object ("Durable Object storage operation exceeded timeout which caused object to be reset"). Because the pagination cursor only advances at the end of a batch, the queue retried the same batch forever — a stuck sync that also spammed error tracking. Replace the lazy-load fan-out with a single nested query per page: - New linear-sync.ts holds TEAM_ISSUES_BATCH_QUERY (issues with creator/assignee/state/comments/attachments inline) plus pure, unit-tested resolveAuthorContact and buildIssueLink transforms. - syncBatch now does one client.client.rawRequest per page (25 issues), then transforms each node — no per-issue round-trips. rawRequest throws on any HTTP/GraphQL error, so a transient 502 retries the cheap query instead of silently degrading per field. - 25 issues/page with comments(first:50)/attachments(first:50) is ~2,500 complexity points, well under Linear's 10,000 cap. - Remove the now-redundant `declare const Buffer` shim and add @types/node (matching the asana connector) so the real Buffer type applies at the webhook parseData call. Backwards compatible: source format (linear:issue:<id>), the syncBatch callback signature, and SyncState shape are unchanged. 8 vitest cases; build and lint green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

syncBatch reached its final page and cleared sync state but never called channelSyncCompleted, so the runtime never stamped initial_sync_completed_at. The connection stayed in the "Syncing" state until the stuck-sync watchdog gave up after 3 attempts and flipped it to "Reconnect" — an endless reconnect loop even though the backfill actually finished. syncBatch only ever runs for the initial backfill (both startBatchSync callers set initialSync; webhooks drive incremental), so signal completion in the terminal branch. Adds linear.test.ts: signals once on the final page, stays quiet while more pages remain. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…sync # Conflicts: # connectors/linear/src/linear.ts

KrisBraun · 2026-06-20T17:55:36Z

Why

Two distinct production failures on the Linear connector, both surfacing as a stuck/looping connection.

1. DO-storage-timeout stuck sync (the GraphQL rewrite)

syncBatch pulled 50 issues/batch and the old convertIssueToLink lazy-loaded each issue's creator/assignee/state/comments/attachments (and each comment's user) through the Linear SDK — every relation is a separate GraphQL round-trip, ~250+ sequential calls per execution. When Linear degraded (502s), an execution stretched long enough to exceed the per-tool Storage Durable Object timeout → DO reset. That error isn't transient-classified, so the run-queue retried — but the pagination cursor only advances at the end of syncBatch, so the retry re-ran the same batch forever (stuck "Syncing").

Fix: one nested GraphQL query per page (TEAM_ISSUES_BATCH_QUERY in the new linear-sync.ts) replaces all the lazy-loads. ISSUES_PER_PAGE=25 (≈2,500 complexity pts, 4× under Linear's 10k cap). Pure buildIssueLink / resolveAuthorContact (unit-tested). A 502 now throws once and retries a single cheap query instead of fanning out per field.

2. Endless "Reconnect" loop (re-establish `channelSyncCompleted`)

The connector's syncBatch finished the final page by just clearing sync state — it never called channelSyncCompleted, so the runtime never stamped initial_sync_completed_at. The connection sat in "Syncing" until the stuck-sync watchdog (recover-stuck-syncs.ts, MAX_INITIAL_SYNC_ATTEMPTS=3) gave up and flipped it to "Reconnect" — then each reconnect restarted the loop (~hourly). Confirmed in prod against a real account: current Linear connection had initial_sync_attempts=3, initial_sync_completed_at=NULL, needs_reauth_at set, while the connector was otherwise healthy (data flowing, zero sync errors in error-tracking).

#212 already landed this signal on main in the oldsyncBatch; this branch forked before that and rewrote the whole method, so the call had to be re-established in the new terminal branch (gated on state.initialSync, matching #212). Merged main in so the branch carries both.

Tests

New linear.test.ts (slack.test.ts-style in-memory store + mocked tool-shed): signals channelSyncCompleted once on the final page; stays quiet while more pages remain.
linear-sync.test.ts (8) covers buildIssueLink / resolveAuthorContact.
pnpm test (10/10), pnpm build (tsc), plot lint all green.

No changeset (connector-only change). Backwards-compatible: source, callback signatures, and SyncState shape unchanged.

🤖 Generated with Claude Code

syncBatch lazy-loaded each issue's creator, assignee, state, comments, and attachments through the Linear SDK — every relation is a separate GraphQL round-trip, so a 50-issue batch fired 250+ sequential calls in a single execution. When Linear was degraded (the GraphQL 502s in the logs), that execution stretched long enough for a Storage Durable Object operation to exceed its timeout and reset the object ("Durable Object storage operation exceeded timeout which caused object to be reset"). Because the pagination cursor only advances at the end of a batch, the queue retried the same batch forever — a stuck sync that also spammed error tracking. Replace the lazy-load fan-out with a single nested query per page: - New linear-sync.ts holds TEAM_ISSUES_BATCH_QUERY (issues with creator/assignee/state/comments/attachments inline) plus pure, unit-tested resolveAuthorContact and buildIssueLink transforms. - syncBatch now does one client.client.rawRequest per page (25 issues), then transforms each node — no per-issue round-trips. rawRequest throws on any HTTP/GraphQL error, so a transient 502 retries the cheap query instead of silently degrading per field. - 25 issues/page with comments(first:50)/attachments(first:50) is ~2,500 complexity points, well under Linear's 10,000 cap. - Remove the now-redundant `declare const Buffer` shim and add @types/node (matching the asana connector) so the real Buffer type applies at the webhook parseData call. Backwards compatible: source format (linear:issue:<id>), the syncBatch callback signature, and SyncState shape are unchanged. 8 vitest cases; build and lint green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

syncBatch reached its final page and cleared sync state but never called channelSyncCompleted, so the runtime never stamped initial_sync_completed_at. The connection stayed in the "Syncing" state until the stuck-sync watchdog gave up after 3 attempts and flipped it to "Reconnect" — an endless reconnect loop even though the backfill actually finished. syncBatch only ever runs for the initial backfill (both startBatchSync callers set initialSync; webhooks drive incremental), so signal completion in the terminal branch. Adds linear.test.ts: signals once on the final page, stays quiet while more pages remain. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…sync # Conflicts: # connectors/linear/src/linear.ts

KrisBraun · 2026-06-20T17:55:36Z

Why

Two distinct production failures on the Linear connector, both surfacing as a stuck/looping connection.

1. DO-storage-timeout stuck sync (the GraphQL rewrite)

syncBatch pulled 50 issues/batch and the old convertIssueToLink lazy-loaded each issue's creator/assignee/state/comments/attachments (and each comment's user) through the Linear SDK — every relation is a separate GraphQL round-trip, ~250+ sequential calls per execution. When Linear degraded (502s), an execution stretched long enough to exceed the per-tool Storage Durable Object timeout → DO reset. That error isn't transient-classified, so the run-queue retried — but the pagination cursor only advances at the end of syncBatch, so the retry re-ran the same batch forever (stuck "Syncing").

Fix: one nested GraphQL query per page (TEAM_ISSUES_BATCH_QUERY in the new linear-sync.ts) replaces all the lazy-loads. ISSUES_PER_PAGE=25 (≈2,500 complexity pts, 4× under Linear's 10k cap). Pure buildIssueLink / resolveAuthorContact (unit-tested). A 502 now throws once and retries a single cheap query instead of fanning out per field.

2. Endless "Reconnect" loop (re-establish `channelSyncCompleted`)

The connector's syncBatch finished the final page by just clearing sync state — it never called channelSyncCompleted, so the runtime never stamped initial_sync_completed_at. The connection sat in "Syncing" until the stuck-sync watchdog (recover-stuck-syncs.ts, MAX_INITIAL_SYNC_ATTEMPTS=3) gave up and flipped it to "Reconnect" — then each reconnect restarted the loop (~hourly). Confirmed in prod against a real account: current Linear connection had initial_sync_attempts=3, initial_sync_completed_at=NULL, needs_reauth_at set, while the connector was otherwise healthy (data flowing, zero sync errors in error-tracking).

#212 already landed this signal on main in the oldsyncBatch; this branch forked before that and rewrote the whole method, so the call had to be re-established in the new terminal branch (gated on state.initialSync, matching #212). Merged main in so the branch carries both.

Tests

New linear.test.ts (slack.test.ts-style in-memory store + mocked tool-shed): signals channelSyncCompleted once on the final page; stays quiet while more pages remain.
linear-sync.test.ts (8) covers buildIssueLink / resolveAuthorContact.
pnpm test (10/10), pnpm build (tsc), plot lint all green.

No changeset (connector-only change). Backwards-compatible: source, callback signatures, and SyncState shape unchanged.

🤖 Generated with Claude Code

syncBatch lazy-loaded each issue's creator, assignee, state, comments, and attachments through the Linear SDK — every relation is a separate GraphQL round-trip, so a 50-issue batch fired 250+ sequential calls in a single execution. When Linear was degraded (the GraphQL 502s in the logs), that execution stretched long enough for a Storage Durable Object operation to exceed its timeout and reset the object ("Durable Object storage operation exceeded timeout which caused object to be reset"). Because the pagination cursor only advances at the end of a batch, the queue retried the same batch forever — a stuck sync that also spammed error tracking. Replace the lazy-load fan-out with a single nested query per page: - New linear-sync.ts holds TEAM_ISSUES_BATCH_QUERY (issues with creator/assignee/state/comments/attachments inline) plus pure, unit-tested resolveAuthorContact and buildIssueLink transforms. - syncBatch now does one client.client.rawRequest per page (25 issues), then transforms each node — no per-issue round-trips. rawRequest throws on any HTTP/GraphQL error, so a transient 502 retries the cheap query instead of silently degrading per field. - 25 issues/page with comments(first:50)/attachments(first:50) is ~2,500 complexity points, well under Linear's 10,000 cap. - Remove the now-redundant `declare const Buffer` shim and add @types/node (matching the asana connector) so the real Buffer type applies at the webhook parseData call. Backwards compatible: source format (linear:issue:<id>), the syncBatch callback signature, and SyncState shape are unchanged. 8 vitest cases; build and lint green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

syncBatch reached its final page and cleared sync state but never called channelSyncCompleted, so the runtime never stamped initial_sync_completed_at. The connection stayed in the "Syncing" state until the stuck-sync watchdog gave up after 3 attempts and flipped it to "Reconnect" — an endless reconnect loop even though the backfill actually finished. syncBatch only ever runs for the initial backfill (both startBatchSync callers set initialSync; webhooks drive incremental), so signal completion in the terminal branch. Adds linear.test.ts: signals once on the final page, stays quiet while more pages remain. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…sync # Conflicts: # connectors/linear/src/linear.ts

KrisBraun · 2026-06-20T17:55:36Z

Why

Two distinct production failures on the Linear connector, both surfacing as a stuck/looping connection.

1. DO-storage-timeout stuck sync (the GraphQL rewrite)

syncBatch pulled 50 issues/batch and the old convertIssueToLink lazy-loaded each issue's creator/assignee/state/comments/attachments (and each comment's user) through the Linear SDK — every relation is a separate GraphQL round-trip, ~250+ sequential calls per execution. When Linear degraded (502s), an execution stretched long enough to exceed the per-tool Storage Durable Object timeout → DO reset. That error isn't transient-classified, so the run-queue retried — but the pagination cursor only advances at the end of syncBatch, so the retry re-ran the same batch forever (stuck "Syncing").

Fix: one nested GraphQL query per page (TEAM_ISSUES_BATCH_QUERY in the new linear-sync.ts) replaces all the lazy-loads. ISSUES_PER_PAGE=25 (≈2,500 complexity pts, 4× under Linear's 10k cap). Pure buildIssueLink / resolveAuthorContact (unit-tested). A 502 now throws once and retries a single cheap query instead of fanning out per field.

2. Endless "Reconnect" loop (re-establish `channelSyncCompleted`)

The connector's syncBatch finished the final page by just clearing sync state — it never called channelSyncCompleted, so the runtime never stamped initial_sync_completed_at. The connection sat in "Syncing" until the stuck-sync watchdog (recover-stuck-syncs.ts, MAX_INITIAL_SYNC_ATTEMPTS=3) gave up and flipped it to "Reconnect" — then each reconnect restarted the loop (~hourly). Confirmed in prod against a real account: current Linear connection had initial_sync_attempts=3, initial_sync_completed_at=NULL, needs_reauth_at set, while the connector was otherwise healthy (data flowing, zero sync errors in error-tracking).

#212 already landed this signal on main in the oldsyncBatch; this branch forked before that and rewrote the whole method, so the call had to be re-established in the new terminal branch (gated on state.initialSync, matching #212). Merged main in so the branch carries both.

Tests

New linear.test.ts (slack.test.ts-style in-memory store + mocked tool-shed): signals channelSyncCompleted once on the final page; stays quiet while more pages remain.
linear-sync.test.ts (8) covers buildIssueLink / resolveAuthorContact.
pnpm test (10/10), pnpm build (tsc), plot lint all green.

No changeset (connector-only change). Backwards-compatible: source, callback signatures, and SyncState shape unchanged.

🤖 Generated with Claude Code

syncBatch lazy-loaded each issue's creator, assignee, state, comments, and attachments through the Linear SDK — every relation is a separate GraphQL round-trip, so a 50-issue batch fired 250+ sequential calls in a single execution. When Linear was degraded (the GraphQL 502s in the logs), that execution stretched long enough for a Storage Durable Object operation to exceed its timeout and reset the object ("Durable Object storage operation exceeded timeout which caused object to be reset"). Because the pagination cursor only advances at the end of a batch, the queue retried the same batch forever — a stuck sync that also spammed error tracking. Replace the lazy-load fan-out with a single nested query per page: - New linear-sync.ts holds TEAM_ISSUES_BATCH_QUERY (issues with creator/assignee/state/comments/attachments inline) plus pure, unit-tested resolveAuthorContact and buildIssueLink transforms. - syncBatch now does one client.client.rawRequest per page (25 issues), then transforms each node — no per-issue round-trips. rawRequest throws on any HTTP/GraphQL error, so a transient 502 retries the cheap query instead of silently degrading per field. - 25 issues/page with comments(first:50)/attachments(first:50) is ~2,500 complexity points, well under Linear's 10,000 cap. - Remove the now-redundant `declare const Buffer` shim and add @types/node (matching the asana connector) so the real Buffer type applies at the webhook parseData call. Backwards compatible: source format (linear:issue:<id>), the syncBatch callback signature, and SyncState shape are unchanged. 8 vitest cases; build and lint green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

syncBatch reached its final page and cleared sync state but never called channelSyncCompleted, so the runtime never stamped initial_sync_completed_at. The connection stayed in the "Syncing" state until the stuck-sync watchdog gave up after 3 attempts and flipped it to "Reconnect" — an endless reconnect loop even though the backfill actually finished. syncBatch only ever runs for the initial backfill (both startBatchSync callers set initialSync; webhooks drive incremental), so signal completion in the terminal branch. Adds linear.test.ts: signals once on the final page, stays quiet while more pages remain. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…sync # Conflicts: # connectors/linear/src/linear.ts

KrisBraun · 2026-06-20T17:55:36Z

Why

Two distinct production failures on the Linear connector, both surfacing as a stuck/looping connection.

1. DO-storage-timeout stuck sync (the GraphQL rewrite)

syncBatch pulled 50 issues/batch and the old convertIssueToLink lazy-loaded each issue's creator/assignee/state/comments/attachments (and each comment's user) through the Linear SDK — every relation is a separate GraphQL round-trip, ~250+ sequential calls per execution. When Linear degraded (502s), an execution stretched long enough to exceed the per-tool Storage Durable Object timeout → DO reset. That error isn't transient-classified, so the run-queue retried — but the pagination cursor only advances at the end of syncBatch, so the retry re-ran the same batch forever (stuck "Syncing").

Fix: one nested GraphQL query per page (TEAM_ISSUES_BATCH_QUERY in the new linear-sync.ts) replaces all the lazy-loads. ISSUES_PER_PAGE=25 (≈2,500 complexity pts, 4× under Linear's 10k cap). Pure buildIssueLink / resolveAuthorContact (unit-tested). A 502 now throws once and retries a single cheap query instead of fanning out per field.

2. Endless "Reconnect" loop (re-establish `channelSyncCompleted`)

The connector's syncBatch finished the final page by just clearing sync state — it never called channelSyncCompleted, so the runtime never stamped initial_sync_completed_at. The connection sat in "Syncing" until the stuck-sync watchdog (recover-stuck-syncs.ts, MAX_INITIAL_SYNC_ATTEMPTS=3) gave up and flipped it to "Reconnect" — then each reconnect restarted the loop (~hourly). Confirmed in prod against a real account: current Linear connection had initial_sync_attempts=3, initial_sync_completed_at=NULL, needs_reauth_at set, while the connector was otherwise healthy (data flowing, zero sync errors in error-tracking).

#212 already landed this signal on main in the oldsyncBatch; this branch forked before that and rewrote the whole method, so the call had to be re-established in the new terminal branch (gated on state.initialSync, matching #212). Merged main in so the branch carries both.

Tests

New linear.test.ts (slack.test.ts-style in-memory store + mocked tool-shed): signals channelSyncCompleted once on the final page; stays quiet while more pages remain.
linear-sync.test.ts (8) covers buildIssueLink / resolveAuthorContact.
pnpm test (10/10), pnpm build (tsc), plot lint all green.

No changeset (connector-only change). Backwards-compatible: source, callback signatures, and SyncState shape unchanged.

🤖 Generated with Claude Code

syncBatch lazy-loaded each issue's creator, assignee, state, comments, and attachments through the Linear SDK — every relation is a separate GraphQL round-trip, so a 50-issue batch fired 250+ sequential calls in a single execution. When Linear was degraded (the GraphQL 502s in the logs), that execution stretched long enough for a Storage Durable Object operation to exceed its timeout and reset the object ("Durable Object storage operation exceeded timeout which caused object to be reset"). Because the pagination cursor only advances at the end of a batch, the queue retried the same batch forever — a stuck sync that also spammed error tracking. Replace the lazy-load fan-out with a single nested query per page: - New linear-sync.ts holds TEAM_ISSUES_BATCH_QUERY (issues with creator/assignee/state/comments/attachments inline) plus pure, unit-tested resolveAuthorContact and buildIssueLink transforms. - syncBatch now does one client.client.rawRequest per page (25 issues), then transforms each node — no per-issue round-trips. rawRequest throws on any HTTP/GraphQL error, so a transient 502 retries the cheap query instead of silently degrading per field. - 25 issues/page with comments(first:50)/attachments(first:50) is ~2,500 complexity points, well under Linear's 10,000 cap. - Remove the now-redundant `declare const Buffer` shim and add @types/node (matching the asana connector) so the real Buffer type applies at the webhook parseData call. Backwards compatible: source format (linear:issue:<id>), the syncBatch callback signature, and SyncState shape are unchanged. 8 vitest cases; build and lint green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

syncBatch reached its final page and cleared sync state but never called channelSyncCompleted, so the runtime never stamped initial_sync_completed_at. The connection stayed in the "Syncing" state until the stuck-sync watchdog gave up after 3 attempts and flipped it to "Reconnect" — an endless reconnect loop even though the backfill actually finished. syncBatch only ever runs for the initial backfill (both startBatchSync callers set initialSync; webhooks drive incremental), so signal completion in the terminal branch. Adds linear.test.ts: signals once on the final page, stays quiet while more pages remain. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…sync # Conflicts: # connectors/linear/src/linear.ts

KrisBraun · 2026-06-20T17:55:36Z

Why

Two distinct production failures on the Linear connector, both surfacing as a stuck/looping connection.

1. DO-storage-timeout stuck sync (the GraphQL rewrite)

syncBatch pulled 50 issues/batch and the old convertIssueToLink lazy-loaded each issue's creator/assignee/state/comments/attachments (and each comment's user) through the Linear SDK — every relation is a separate GraphQL round-trip, ~250+ sequential calls per execution. When Linear degraded (502s), an execution stretched long enough to exceed the per-tool Storage Durable Object timeout → DO reset. That error isn't transient-classified, so the run-queue retried — but the pagination cursor only advances at the end of syncBatch, so the retry re-ran the same batch forever (stuck "Syncing").

Fix: one nested GraphQL query per page (TEAM_ISSUES_BATCH_QUERY in the new linear-sync.ts) replaces all the lazy-loads. ISSUES_PER_PAGE=25 (≈2,500 complexity pts, 4× under Linear's 10k cap). Pure buildIssueLink / resolveAuthorContact (unit-tested). A 502 now throws once and retries a single cheap query instead of fanning out per field.

2. Endless "Reconnect" loop (re-establish `channelSyncCompleted`)

The connector's syncBatch finished the final page by just clearing sync state — it never called channelSyncCompleted, so the runtime never stamped initial_sync_completed_at. The connection sat in "Syncing" until the stuck-sync watchdog (recover-stuck-syncs.ts, MAX_INITIAL_SYNC_ATTEMPTS=3) gave up and flipped it to "Reconnect" — then each reconnect restarted the loop (~hourly). Confirmed in prod against a real account: current Linear connection had initial_sync_attempts=3, initial_sync_completed_at=NULL, needs_reauth_at set, while the connector was otherwise healthy (data flowing, zero sync errors in error-tracking).

#212 already landed this signal on main in the oldsyncBatch; this branch forked before that and rewrote the whole method, so the call had to be re-established in the new terminal branch (gated on state.initialSync, matching #212). Merged main in so the branch carries both.

Tests

New linear.test.ts (slack.test.ts-style in-memory store + mocked tool-shed): signals channelSyncCompleted once on the final page; stays quiet while more pages remain.
linear-sync.test.ts (8) covers buildIssueLink / resolveAuthorContact.
pnpm test (10/10), pnpm build (tsc), plot lint all green.

No changeset (connector-only change). Backwards-compatible: source, callback signatures, and SyncState shape unchanged.

🤖 Generated with Claude Code

syncBatch lazy-loaded each issue's creator, assignee, state, comments, and attachments through the Linear SDK — every relation is a separate GraphQL round-trip, so a 50-issue batch fired 250+ sequential calls in a single execution. When Linear was degraded (the GraphQL 502s in the logs), that execution stretched long enough for a Storage Durable Object operation to exceed its timeout and reset the object ("Durable Object storage operation exceeded timeout which caused object to be reset"). Because the pagination cursor only advances at the end of a batch, the queue retried the same batch forever — a stuck sync that also spammed error tracking. Replace the lazy-load fan-out with a single nested query per page: - New linear-sync.ts holds TEAM_ISSUES_BATCH_QUERY (issues with creator/assignee/state/comments/attachments inline) plus pure, unit-tested resolveAuthorContact and buildIssueLink transforms. - syncBatch now does one client.client.rawRequest per page (25 issues), then transforms each node — no per-issue round-trips. rawRequest throws on any HTTP/GraphQL error, so a transient 502 retries the cheap query instead of silently degrading per field. - 25 issues/page with comments(first:50)/attachments(first:50) is ~2,500 complexity points, well under Linear's 10,000 cap. - Remove the now-redundant `declare const Buffer` shim and add @types/node (matching the asana connector) so the real Buffer type applies at the webhook parseData call. Backwards compatible: source format (linear:issue:<id>), the syncBatch callback signature, and SyncState shape are unchanged. 8 vitest cases; build and lint green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

syncBatch reached its final page and cleared sync state but never called channelSyncCompleted, so the runtime never stamped initial_sync_completed_at. The connection stayed in the "Syncing" state until the stuck-sync watchdog gave up after 3 attempts and flipped it to "Reconnect" — an endless reconnect loop even though the backfill actually finished. syncBatch only ever runs for the initial backfill (both startBatchSync callers set initialSync; webhooks drive incremental), so signal completion in the terminal branch. Adds linear.test.ts: signals once on the final page, stays quiet while more pages remain. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…sync # Conflicts: # connectors/linear/src/linear.ts

KrisBraun · 2026-06-20T17:55:36Z

Why

Two distinct production failures on the Linear connector, both surfacing as a stuck/looping connection.

1. DO-storage-timeout stuck sync (the GraphQL rewrite)

syncBatch pulled 50 issues/batch and the old convertIssueToLink lazy-loaded each issue's creator/assignee/state/comments/attachments (and each comment's user) through the Linear SDK — every relation is a separate GraphQL round-trip, ~250+ sequential calls per execution. When Linear degraded (502s), an execution stretched long enough to exceed the per-tool Storage Durable Object timeout → DO reset. That error isn't transient-classified, so the run-queue retried — but the pagination cursor only advances at the end of syncBatch, so the retry re-ran the same batch forever (stuck "Syncing").

Fix: one nested GraphQL query per page (TEAM_ISSUES_BATCH_QUERY in the new linear-sync.ts) replaces all the lazy-loads. ISSUES_PER_PAGE=25 (≈2,500 complexity pts, 4× under Linear's 10k cap). Pure buildIssueLink / resolveAuthorContact (unit-tested). A 502 now throws once and retries a single cheap query instead of fanning out per field.

2. Endless "Reconnect" loop (re-establish `channelSyncCompleted`)

The connector's syncBatch finished the final page by just clearing sync state — it never called channelSyncCompleted, so the runtime never stamped initial_sync_completed_at. The connection sat in "Syncing" until the stuck-sync watchdog (recover-stuck-syncs.ts, MAX_INITIAL_SYNC_ATTEMPTS=3) gave up and flipped it to "Reconnect" — then each reconnect restarted the loop (~hourly). Confirmed in prod against a real account: current Linear connection had initial_sync_attempts=3, initial_sync_completed_at=NULL, needs_reauth_at set, while the connector was otherwise healthy (data flowing, zero sync errors in error-tracking).

#212 already landed this signal on main in the oldsyncBatch; this branch forked before that and rewrote the whole method, so the call had to be re-established in the new terminal branch (gated on state.initialSync, matching #212). Merged main in so the branch carries both.

Tests

New linear.test.ts (slack.test.ts-style in-memory store + mocked tool-shed): signals channelSyncCompleted once on the final page; stays quiet while more pages remain.
linear-sync.test.ts (8) covers buildIssueLink / resolveAuthorContact.
pnpm test (10/10), pnpm build (tsc), plot lint all green.

No changeset (connector-only change). Backwards-compatible: source, callback signatures, and SyncState shape unchanged.

🤖 Generated with Claude Code

syncBatch lazy-loaded each issue's creator, assignee, state, comments, and attachments through the Linear SDK — every relation is a separate GraphQL round-trip, so a 50-issue batch fired 250+ sequential calls in a single execution. When Linear was degraded (the GraphQL 502s in the logs), that execution stretched long enough for a Storage Durable Object operation to exceed its timeout and reset the object ("Durable Object storage operation exceeded timeout which caused object to be reset"). Because the pagination cursor only advances at the end of a batch, the queue retried the same batch forever — a stuck sync that also spammed error tracking. Replace the lazy-load fan-out with a single nested query per page: - New linear-sync.ts holds TEAM_ISSUES_BATCH_QUERY (issues with creator/assignee/state/comments/attachments inline) plus pure, unit-tested resolveAuthorContact and buildIssueLink transforms. - syncBatch now does one client.client.rawRequest per page (25 issues), then transforms each node — no per-issue round-trips. rawRequest throws on any HTTP/GraphQL error, so a transient 502 retries the cheap query instead of silently degrading per field. - 25 issues/page with comments(first:50)/attachments(first:50) is ~2,500 complexity points, well under Linear's 10,000 cap. - Remove the now-redundant `declare const Buffer` shim and add @types/node (matching the asana connector) so the real Buffer type applies at the webhook parseData call. Backwards compatible: source format (linear:issue:<id>), the syncBatch callback signature, and SyncState shape are unchanged. 8 vitest cases; build and lint green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

syncBatch reached its final page and cleared sync state but never called channelSyncCompleted, so the runtime never stamped initial_sync_completed_at. The connection stayed in the "Syncing" state until the stuck-sync watchdog gave up after 3 attempts and flipped it to "Reconnect" — an endless reconnect loop even though the backfill actually finished. syncBatch only ever runs for the initial backfill (both startBatchSync callers set initialSync; webhooks drive incremental), so signal completion in the terminal branch. Adds linear.test.ts: signals once on the final page, stays quiet while more pages remain. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…sync # Conflicts: # connectors/linear/src/linear.ts

KrisBraun · 2026-06-20T17:55:36Z

Why

Two distinct production failures on the Linear connector, both surfacing as a stuck/looping connection.

1. DO-storage-timeout stuck sync (the GraphQL rewrite)

syncBatch pulled 50 issues/batch and the old convertIssueToLink lazy-loaded each issue's creator/assignee/state/comments/attachments (and each comment's user) through the Linear SDK — every relation is a separate GraphQL round-trip, ~250+ sequential calls per execution. When Linear degraded (502s), an execution stretched long enough to exceed the per-tool Storage Durable Object timeout → DO reset. That error isn't transient-classified, so the run-queue retried — but the pagination cursor only advances at the end of syncBatch, so the retry re-ran the same batch forever (stuck "Syncing").

Fix: one nested GraphQL query per page (TEAM_ISSUES_BATCH_QUERY in the new linear-sync.ts) replaces all the lazy-loads. ISSUES_PER_PAGE=25 (≈2,500 complexity pts, 4× under Linear's 10k cap). Pure buildIssueLink / resolveAuthorContact (unit-tested). A 502 now throws once and retries a single cheap query instead of fanning out per field.

2. Endless "Reconnect" loop (re-establish `channelSyncCompleted`)

The connector's syncBatch finished the final page by just clearing sync state — it never called channelSyncCompleted, so the runtime never stamped initial_sync_completed_at. The connection sat in "Syncing" until the stuck-sync watchdog (recover-stuck-syncs.ts, MAX_INITIAL_SYNC_ATTEMPTS=3) gave up and flipped it to "Reconnect" — then each reconnect restarted the loop (~hourly). Confirmed in prod against a real account: current Linear connection had initial_sync_attempts=3, initial_sync_completed_at=NULL, needs_reauth_at set, while the connector was otherwise healthy (data flowing, zero sync errors in error-tracking).

#212 already landed this signal on main in the oldsyncBatch; this branch forked before that and rewrote the whole method, so the call had to be re-established in the new terminal branch (gated on state.initialSync, matching #212). Merged main in so the branch carries both.

Tests

New linear.test.ts (slack.test.ts-style in-memory store + mocked tool-shed): signals channelSyncCompleted once on the final page; stays quiet while more pages remain.
linear-sync.test.ts (8) covers buildIssueLink / resolveAuthorContact.
pnpm test (10/10), pnpm build (tsc), plot lint all green.

No changeset (connector-only change). Backwards-compatible: source, callback signatures, and SyncState shape unchanged.

🤖 Generated with Claude Code

syncBatch lazy-loaded each issue's creator, assignee, state, comments, and attachments through the Linear SDK — every relation is a separate GraphQL round-trip, so a 50-issue batch fired 250+ sequential calls in a single execution. When Linear was degraded (the GraphQL 502s in the logs), that execution stretched long enough for a Storage Durable Object operation to exceed its timeout and reset the object ("Durable Object storage operation exceeded timeout which caused object to be reset"). Because the pagination cursor only advances at the end of a batch, the queue retried the same batch forever — a stuck sync that also spammed error tracking. Replace the lazy-load fan-out with a single nested query per page: - New linear-sync.ts holds TEAM_ISSUES_BATCH_QUERY (issues with creator/assignee/state/comments/attachments inline) plus pure, unit-tested resolveAuthorContact and buildIssueLink transforms. - syncBatch now does one client.client.rawRequest per page (25 issues), then transforms each node — no per-issue round-trips. rawRequest throws on any HTTP/GraphQL error, so a transient 502 retries the cheap query instead of silently degrading per field. - 25 issues/page with comments(first:50)/attachments(first:50) is ~2,500 complexity points, well under Linear's 10,000 cap. - Remove the now-redundant `declare const Buffer` shim and add @types/node (matching the asana connector) so the real Buffer type applies at the webhook parseData call. Backwards compatible: source format (linear:issue:<id>), the syncBatch callback signature, and SyncState shape are unchanged. 8 vitest cases; build and lint green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

syncBatch reached its final page and cleared sync state but never called channelSyncCompleted, so the runtime never stamped initial_sync_completed_at. The connection stayed in the "Syncing" state until the stuck-sync watchdog gave up after 3 attempts and flipped it to "Reconnect" — an endless reconnect loop even though the backfill actually finished. syncBatch only ever runs for the initial backfill (both startBatchSync callers set initialSync; webhooks drive incremental), so signal completion in the terminal branch. Adds linear.test.ts: signals once on the final page, stays quiet while more pages remain. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…sync # Conflicts: # connectors/linear/src/linear.ts

KrisBraunand others added 3 commits June 20, 2026 13:36

Merge remote-tracking branch 'origin/main' into linear-graphql-batch-…
f267fbd
…sync # Conflicts: # connectors/linear/src/linear.ts

KrisBraun merged commit ab36078 into mainJun 20, 2026
1 check passed

KrisBraun deleted the linear-graphql-batch-sync branch June 20, 2026 17:58

KrisBraunand others added 3 commits June 20, 2026 13:36

Merge remote-tracking branch 'origin/main' into linear-graphql-batch-…
f267fbd
…sync # Conflicts: # connectors/linear/src/linear.ts

KrisBraun merged commit ab36078 into mainJun 20, 2026
1 check passed

KrisBraun deleted the linear-graphql-batch-sync branch June 20, 2026 17:58

KrisBraunand others added 3 commits June 20, 2026 13:36

Merge remote-tracking branch 'origin/main' into linear-graphql-batch-…
f267fbd
…sync # Conflicts: # connectors/linear/src/linear.ts

KrisBraun merged commit ab36078 into mainJun 20, 2026
1 check passed

KrisBraun deleted the linear-graphql-batch-sync branch June 20, 2026 17:58

KrisBraunand others added 3 commits June 20, 2026 13:36

Merge remote-tracking branch 'origin/main' into linear-graphql-batch-…
f267fbd
…sync # Conflicts: # connectors/linear/src/linear.ts

KrisBraun merged commit ab36078 into mainJun 20, 2026
1 check passed

KrisBraun deleted the linear-graphql-batch-sync branch June 20, 2026 17:58

KrisBraunand others added 3 commits June 20, 2026 13:36

Merge remote-tracking branch 'origin/main' into linear-graphql-batch-…
f267fbd
…sync # Conflicts: # connectors/linear/src/linear.ts

KrisBraun merged commit ab36078 into mainJun 20, 2026
1 check passed

KrisBraun deleted the linear-graphql-batch-sync branch June 20, 2026 17:58

KrisBraunand others added 3 commits June 20, 2026 13:36

Merge remote-tracking branch 'origin/main' into linear-graphql-batch-…
f267fbd
…sync # Conflicts: # connectors/linear/src/linear.ts

KrisBraun merged commit ab36078 into mainJun 20, 2026
1 check passed

KrisBraun deleted the linear-graphql-batch-sync branch June 20, 2026 17:58

KrisBraunand others added 3 commits June 20, 2026 13:36

Merge remote-tracking branch 'origin/main' into linear-graphql-batch-…
f267fbd
…sync # Conflicts: # connectors/linear/src/linear.ts

KrisBraun merged commit ab36078 into mainJun 20, 2026
1 check passed

KrisBraun deleted the linear-graphql-batch-sync branch June 20, 2026 17:58

KrisBraunand others added 3 commits June 20, 2026 13:36

Merge remote-tracking branch 'origin/main' into linear-graphql-batch-…
f267fbd
…sync # Conflicts: # connectors/linear/src/linear.ts

KrisBraun merged commit ab36078 into mainJun 20, 2026
1 check passed

KrisBraun deleted the linear-graphql-batch-sync branch June 20, 2026 17:58

Uh oh!

Conversation

KrisBraun commented Jun 20, 2026

Why

1. DO-storage-timeout stuck sync (the GraphQL rewrite)

2. Endless "Reconnect" loop (re-establish channelSyncCompleted)

Tests

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

KrisBraun commented Jun 20, 2026

Why

1. DO-storage-timeout stuck sync (the GraphQL rewrite)

2. Endless "Reconnect" loop (re-establish channelSyncCompleted)

Tests

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

KrisBraun commented Jun 20, 2026

Why

1. DO-storage-timeout stuck sync (the GraphQL rewrite)

2. Endless "Reconnect" loop (re-establish channelSyncCompleted)

Tests

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

KrisBraun commented Jun 20, 2026

Why

1. DO-storage-timeout stuck sync (the GraphQL rewrite)

2. Endless "Reconnect" loop (re-establish channelSyncCompleted)

Tests

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

KrisBraun commented Jun 20, 2026

Why

1. DO-storage-timeout stuck sync (the GraphQL rewrite)

2. Endless "Reconnect" loop (re-establish channelSyncCompleted)

Tests

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

2. Endless "Reconnect" loop (re-establish `channelSyncCompleted`)

2. Endless "Reconnect" loop (re-establish `channelSyncCompleted`)

2. Endless "Reconnect" loop (re-establish `channelSyncCompleted`)

2. Endless "Reconnect" loop (re-establish `channelSyncCompleted`)

2. Endless "Reconnect" loop (re-establish `channelSyncCompleted`)

2. Endless "Reconnect" loop (re-establish `channelSyncCompleted`)

2. Endless "Reconnect" loop (re-establish `channelSyncCompleted`)