fix(google-tasks): handle deleted task list (404) instead of throwing

[KrisBraun]

Problem

When a user deletes a Google Tasks list but its Plot channel stays enabled, every periodic poll (and the initial backfill) calls listTasks(listId) and gets a permanent 404 Task list not found. That error was thrown unhandled, so it:

1. was captured by error tracking,
2. was retried 3× by RUN_QUEUE (pointless — the list is permanently gone), then
3. dead-lettered (RUN_QUEUE dead-letter:),

repeating every hour per affected user. This was the dominant recent contributor to the catch-all handleTwistOperation PostHog issue 019ed581 (the issue title is misleading — it's a poly-error bucket; the most-recent occurrences were the Google Tasks 404 + its downstream dead-letter).

Fix

• api.ts — introduce a typed GoogleTasksApiError carrying the HTTP status (message format preserved verbatim for log/grouping back-compat) plus an isNotFoundError() helper. request() throws the typed error.
• sync.ts — syncBatchFn and periodicSyncBatchFn now catch a 404 and tear the channel down via the connector's own onChannelDisabledFn (cancel the poll, clear state, archive the list's links) and return { done: true } instead of throwing. onLinkUpdatedFn swallows a 404 write-back (the task/list is gone). Non-404 errors still rethrow.

Treating a deleted list like a disable (archiving its synced tasks) matches existing disable semantics — the tasks no longer exist in the source.

This logic is shared by both the standalone GoogleTasks connector and the combined google connector (both import these functions and schedule the poll under poll:<listId>, routing cancelScheduledTask through the host), so one fix covers both.

Tests

Adds a vitest harness to the connector (mirroring the google connector's setup) with 5 tests:

• syncBatchFn / periodicSyncBatchFn tear the channel down on a 404 (cancel poll, archive links, clear state) without throwing
• both still throw on a non-404 (genuine) failure
• onLinkUpdatedFn swallows a 404 but rethrows non-404

tsc build ✓ · plot lint ✓ · 5/5 tests ✓

Notes

• Connector-only change → no changeset (only twister/ requires one).
• PostHog issue 019ed581 was intentionally not marked resolved (it's a catch-all sharing one fingerprint with still-active DB-pool-timeout/OOM errors). A grouping rule (019f0002-8512-0000-b9ad-e4bffbc85ea4, $exception_values icontains "Google Tasks API error") now de-collapses Google Tasks errors into their own issue so this fix can be verified post-deploy.

🤖 Generated with Claude Code

[KrisBraun]

Problem

When a user deletes a Google Tasks list but its Plot channel stays enabled, every periodic poll (and the initial backfill) calls listTasks(listId) and gets a permanent 404 Task list not found. That error was thrown unhandled, so it:

1. was captured by error tracking,
2. was retried 3× by RUN_QUEUE (pointless — the list is permanently gone), then
3. dead-lettered (RUN_QUEUE dead-letter:),

repeating every hour per affected user. This was the dominant recent contributor to the catch-all handleTwistOperation PostHog issue 019ed581 (the issue title is misleading — it's a poly-error bucket; the most-recent occurrences were the Google Tasks 404 + its downstream dead-letter).

Fix

• api.ts — introduce a typed GoogleTasksApiError carrying the HTTP status (message format preserved verbatim for log/grouping back-compat) plus an isNotFoundError() helper. request() throws the typed error.
• sync.ts — syncBatchFn and periodicSyncBatchFn now catch a 404 and tear the channel down via the connector's own onChannelDisabledFn (cancel the poll, clear state, archive the list's links) and return { done: true } instead of throwing. onLinkUpdatedFn swallows a 404 write-back (the task/list is gone). Non-404 errors still rethrow.

Treating a deleted list like a disable (archiving its synced tasks) matches existing disable semantics — the tasks no longer exist in the source.

This logic is shared by both the standalone GoogleTasks connector and the combined google connector (both import these functions and schedule the poll under poll:<listId>, routing cancelScheduledTask through the host), so one fix covers both.

Tests

Adds a vitest harness to the connector (mirroring the google connector's setup) with 5 tests:

• syncBatchFn / periodicSyncBatchFn tear the channel down on a 404 (cancel poll, archive links, clear state) without throwing
• both still throw on a non-404 (genuine) failure
• onLinkUpdatedFn swallows a 404 but rethrows non-404

tsc build ✓ · plot lint ✓ · 5/5 tests ✓

Notes

• Connector-only change → no changeset (only twister/ requires one).
• PostHog issue 019ed581 was intentionally not marked resolved (it's a catch-all sharing one fingerprint with still-active DB-pool-timeout/OOM errors). A grouping rule (019f0002-8512-0000-b9ad-e4bffbc85ea4, $exception_values icontains "Google Tasks API error") now de-collapses Google Tasks errors into their own issue so this fix can be verified post-deploy.

🤖 Generated with Claude Code

[KrisBraun]

Problem

When a user deletes a Google Tasks list but its Plot channel stays enabled, every periodic poll (and the initial backfill) calls listTasks(listId) and gets a permanent 404 Task list not found. That error was thrown unhandled, so it:

1. was captured by error tracking,
2. was retried 3× by RUN_QUEUE (pointless — the list is permanently gone), then
3. dead-lettered (RUN_QUEUE dead-letter:),

repeating every hour per affected user. This was the dominant recent contributor to the catch-all handleTwistOperation PostHog issue 019ed581 (the issue title is misleading — it's a poly-error bucket; the most-recent occurrences were the Google Tasks 404 + its downstream dead-letter).

Fix

• api.ts — introduce a typed GoogleTasksApiError carrying the HTTP status (message format preserved verbatim for log/grouping back-compat) plus an isNotFoundError() helper. request() throws the typed error.
• sync.ts — syncBatchFn and periodicSyncBatchFn now catch a 404 and tear the channel down via the connector's own onChannelDisabledFn (cancel the poll, clear state, archive the list's links) and return { done: true } instead of throwing. onLinkUpdatedFn swallows a 404 write-back (the task/list is gone). Non-404 errors still rethrow.

Treating a deleted list like a disable (archiving its synced tasks) matches existing disable semantics — the tasks no longer exist in the source.

This logic is shared by both the standalone GoogleTasks connector and the combined google connector (both import these functions and schedule the poll under poll:<listId>, routing cancelScheduledTask through the host), so one fix covers both.

Tests

Adds a vitest harness to the connector (mirroring the google connector's setup) with 5 tests:

• syncBatchFn / periodicSyncBatchFn tear the channel down on a 404 (cancel poll, archive links, clear state) without throwing
• both still throw on a non-404 (genuine) failure
• onLinkUpdatedFn swallows a 404 but rethrows non-404

tsc build ✓ · plot lint ✓ · 5/5 tests ✓

Notes

• Connector-only change → no changeset (only twister/ requires one).
• PostHog issue 019ed581 was intentionally not marked resolved (it's a catch-all sharing one fingerprint with still-active DB-pool-timeout/OOM errors). A grouping rule (019f0002-8512-0000-b9ad-e4bffbc85ea4, $exception_values icontains "Google Tasks API error") now de-collapses Google Tasks errors into their own issue so this fix can be verified post-deploy.

🤖 Generated with Claude Code

[KrisBraun]

Problem

When a user deletes a Google Tasks list but its Plot channel stays enabled, every periodic poll (and the initial backfill) calls listTasks(listId) and gets a permanent 404 Task list not found. That error was thrown unhandled, so it:

1. was captured by error tracking,
2. was retried 3× by RUN_QUEUE (pointless — the list is permanently gone), then
3. dead-lettered (RUN_QUEUE dead-letter:),

repeating every hour per affected user. This was the dominant recent contributor to the catch-all handleTwistOperation PostHog issue 019ed581 (the issue title is misleading — it's a poly-error bucket; the most-recent occurrences were the Google Tasks 404 + its downstream dead-letter).

Fix

• api.ts — introduce a typed GoogleTasksApiError carrying the HTTP status (message format preserved verbatim for log/grouping back-compat) plus an isNotFoundError() helper. request() throws the typed error.
• sync.ts — syncBatchFn and periodicSyncBatchFn now catch a 404 and tear the channel down via the connector's own onChannelDisabledFn (cancel the poll, clear state, archive the list's links) and return { done: true } instead of throwing. onLinkUpdatedFn swallows a 404 write-back (the task/list is gone). Non-404 errors still rethrow.

Treating a deleted list like a disable (archiving its synced tasks) matches existing disable semantics — the tasks no longer exist in the source.

This logic is shared by both the standalone GoogleTasks connector and the combined google connector (both import these functions and schedule the poll under poll:<listId>, routing cancelScheduledTask through the host), so one fix covers both.

Tests

Adds a vitest harness to the connector (mirroring the google connector's setup) with 5 tests:

• syncBatchFn / periodicSyncBatchFn tear the channel down on a 404 (cancel poll, archive links, clear state) without throwing
• both still throw on a non-404 (genuine) failure
• onLinkUpdatedFn swallows a 404 but rethrows non-404

tsc build ✓ · plot lint ✓ · 5/5 tests ✓

Notes

• Connector-only change → no changeset (only twister/ requires one).
• PostHog issue 019ed581 was intentionally not marked resolved (it's a catch-all sharing one fingerprint with still-active DB-pool-timeout/OOM errors). A grouping rule (019f0002-8512-0000-b9ad-e4bffbc85ea4, $exception_values icontains "Google Tasks API error") now de-collapses Google Tasks errors into their own issue so this fix can be verified post-deploy.

🤖 Generated with Claude Code

[KrisBraun]

Problem

When a user deletes a Google Tasks list but its Plot channel stays enabled, every periodic poll (and the initial backfill) calls listTasks(listId) and gets a permanent 404 Task list not found. That error was thrown unhandled, so it:

1. was captured by error tracking,
2. was retried 3× by RUN_QUEUE (pointless — the list is permanently gone), then
3. dead-lettered (RUN_QUEUE dead-letter:),

repeating every hour per affected user. This was the dominant recent contributor to the catch-all handleTwistOperation PostHog issue 019ed581 (the issue title is misleading — it's a poly-error bucket; the most-recent occurrences were the Google Tasks 404 + its downstream dead-letter).

Fix

• api.ts — introduce a typed GoogleTasksApiError carrying the HTTP status (message format preserved verbatim for log/grouping back-compat) plus an isNotFoundError() helper. request() throws the typed error.
• sync.ts — syncBatchFn and periodicSyncBatchFn now catch a 404 and tear the channel down via the connector's own onChannelDisabledFn (cancel the poll, clear state, archive the list's links) and return { done: true } instead of throwing. onLinkUpdatedFn swallows a 404 write-back (the task/list is gone). Non-404 errors still rethrow.

Treating a deleted list like a disable (archiving its synced tasks) matches existing disable semantics — the tasks no longer exist in the source.

This logic is shared by both the standalone GoogleTasks connector and the combined google connector (both import these functions and schedule the poll under poll:<listId>, routing cancelScheduledTask through the host), so one fix covers both.

Tests

Adds a vitest harness to the connector (mirroring the google connector's setup) with 5 tests:

• syncBatchFn / periodicSyncBatchFn tear the channel down on a 404 (cancel poll, archive links, clear state) without throwing
• both still throw on a non-404 (genuine) failure
• onLinkUpdatedFn swallows a 404 but rethrows non-404

tsc build ✓ · plot lint ✓ · 5/5 tests ✓

Notes

• Connector-only change → no changeset (only twister/ requires one).
• PostHog issue 019ed581 was intentionally not marked resolved (it's a catch-all sharing one fingerprint with still-active DB-pool-timeout/OOM errors). A grouping rule (019f0002-8512-0000-b9ad-e4bffbc85ea4, $exception_values icontains "Google Tasks API error") now de-collapses Google Tasks errors into their own issue so this fix can be verified post-deploy.

🤖 Generated with Claude Code

[KrisBraun]

Problem

When a user deletes a Google Tasks list but its Plot channel stays enabled, every periodic poll (and the initial backfill) calls listTasks(listId) and gets a permanent 404 Task list not found. That error was thrown unhandled, so it:

1. was captured by error tracking,
2. was retried 3× by RUN_QUEUE (pointless — the list is permanently gone), then
3. dead-lettered (RUN_QUEUE dead-letter:),

repeating every hour per affected user. This was the dominant recent contributor to the catch-all handleTwistOperation PostHog issue 019ed581 (the issue title is misleading — it's a poly-error bucket; the most-recent occurrences were the Google Tasks 404 + its downstream dead-letter).

Fix

• api.ts — introduce a typed GoogleTasksApiError carrying the HTTP status (message format preserved verbatim for log/grouping back-compat) plus an isNotFoundError() helper. request() throws the typed error.
• sync.ts — syncBatchFn and periodicSyncBatchFn now catch a 404 and tear the channel down via the connector's own onChannelDisabledFn (cancel the poll, clear state, archive the list's links) and return { done: true } instead of throwing. onLinkUpdatedFn swallows a 404 write-back (the task/list is gone). Non-404 errors still rethrow.

Treating a deleted list like a disable (archiving its synced tasks) matches existing disable semantics — the tasks no longer exist in the source.

This logic is shared by both the standalone GoogleTasks connector and the combined google connector (both import these functions and schedule the poll under poll:<listId>, routing cancelScheduledTask through the host), so one fix covers both.

Tests

Adds a vitest harness to the connector (mirroring the google connector's setup) with 5 tests:

• syncBatchFn / periodicSyncBatchFn tear the channel down on a 404 (cancel poll, archive links, clear state) without throwing
• both still throw on a non-404 (genuine) failure
• onLinkUpdatedFn swallows a 404 but rethrows non-404

tsc build ✓ · plot lint ✓ · 5/5 tests ✓

Notes

• Connector-only change → no changeset (only twister/ requires one).
• PostHog issue 019ed581 was intentionally not marked resolved (it's a catch-all sharing one fingerprint with still-active DB-pool-timeout/OOM errors). A grouping rule (019f0002-8512-0000-b9ad-e4bffbc85ea4, $exception_values icontains "Google Tasks API error") now de-collapses Google Tasks errors into their own issue so this fix can be verified post-deploy.

🤖 Generated with Claude Code

[KrisBraun]

Problem

When a user deletes a Google Tasks list but its Plot channel stays enabled, every periodic poll (and the initial backfill) calls listTasks(listId) and gets a permanent 404 Task list not found. That error was thrown unhandled, so it:

1. was captured by error tracking,
2. was retried 3× by RUN_QUEUE (pointless — the list is permanently gone), then
3. dead-lettered (RUN_QUEUE dead-letter:),

repeating every hour per affected user. This was the dominant recent contributor to the catch-all handleTwistOperation PostHog issue 019ed581 (the issue title is misleading — it's a poly-error bucket; the most-recent occurrences were the Google Tasks 404 + its downstream dead-letter).

Fix

• api.ts — introduce a typed GoogleTasksApiError carrying the HTTP status (message format preserved verbatim for log/grouping back-compat) plus an isNotFoundError() helper. request() throws the typed error.
• sync.ts — syncBatchFn and periodicSyncBatchFn now catch a 404 and tear the channel down via the connector's own onChannelDisabledFn (cancel the poll, clear state, archive the list's links) and return { done: true } instead of throwing. onLinkUpdatedFn swallows a 404 write-back (the task/list is gone). Non-404 errors still rethrow.

Treating a deleted list like a disable (archiving its synced tasks) matches existing disable semantics — the tasks no longer exist in the source.

This logic is shared by both the standalone GoogleTasks connector and the combined google connector (both import these functions and schedule the poll under poll:<listId>, routing cancelScheduledTask through the host), so one fix covers both.

Tests

Adds a vitest harness to the connector (mirroring the google connector's setup) with 5 tests:

• syncBatchFn / periodicSyncBatchFn tear the channel down on a 404 (cancel poll, archive links, clear state) without throwing
• both still throw on a non-404 (genuine) failure
• onLinkUpdatedFn swallows a 404 but rethrows non-404

tsc build ✓ · plot lint ✓ · 5/5 tests ✓

Notes

• Connector-only change → no changeset (only twister/ requires one).
• PostHog issue 019ed581 was intentionally not marked resolved (it's a catch-all sharing one fingerprint with still-active DB-pool-timeout/OOM errors). A grouping rule (019f0002-8512-0000-b9ad-e4bffbc85ea4, $exception_values icontains "Google Tasks API error") now de-collapses Google Tasks errors into their own issue so this fix can be verified post-deploy.

🤖 Generated with Claude Code

[KrisBraun]

Problem

When a user deletes a Google Tasks list but its Plot channel stays enabled, every periodic poll (and the initial backfill) calls listTasks(listId) and gets a permanent 404 Task list not found. That error was thrown unhandled, so it:

1. was captured by error tracking,
2. was retried 3× by RUN_QUEUE (pointless — the list is permanently gone), then
3. dead-lettered (RUN_QUEUE dead-letter:),

repeating every hour per affected user. This was the dominant recent contributor to the catch-all handleTwistOperation PostHog issue 019ed581 (the issue title is misleading — it's a poly-error bucket; the most-recent occurrences were the Google Tasks 404 + its downstream dead-letter).

Fix

• api.ts — introduce a typed GoogleTasksApiError carrying the HTTP status (message format preserved verbatim for log/grouping back-compat) plus an isNotFoundError() helper. request() throws the typed error.
• sync.ts — syncBatchFn and periodicSyncBatchFn now catch a 404 and tear the channel down via the connector's own onChannelDisabledFn (cancel the poll, clear state, archive the list's links) and return { done: true } instead of throwing. onLinkUpdatedFn swallows a 404 write-back (the task/list is gone). Non-404 errors still rethrow.

Treating a deleted list like a disable (archiving its synced tasks) matches existing disable semantics — the tasks no longer exist in the source.

This logic is shared by both the standalone GoogleTasks connector and the combined google connector (both import these functions and schedule the poll under poll:<listId>, routing cancelScheduledTask through the host), so one fix covers both.

Tests

Adds a vitest harness to the connector (mirroring the google connector's setup) with 5 tests:

• syncBatchFn / periodicSyncBatchFn tear the channel down on a 404 (cancel poll, archive links, clear state) without throwing
• both still throw on a non-404 (genuine) failure
• onLinkUpdatedFn swallows a 404 but rethrows non-404

tsc build ✓ · plot lint ✓ · 5/5 tests ✓

Notes

• Connector-only change → no changeset (only twister/ requires one).
• PostHog issue 019ed581 was intentionally not marked resolved (it's a catch-all sharing one fingerprint with still-active DB-pool-timeout/OOM errors). A grouping rule (019f0002-8512-0000-b9ad-e4bffbc85ea4, $exception_values icontains "Google Tasks API error") now de-collapses Google Tasks errors into their own issue so this fix can be verified post-deploy.

🤖 Generated with Claude Code