connector-airtable: bound reconcile chain + signal sync completion

[KrisBraun]

Summary

• reconcileComments self-reschedules on every invocation with no chain-depth guard. In production a single Airtable instance ran the chain fast enough to starve the shared run-production queue for hours, blocking sync recovery for 4 unrelated users. We've stopped the immediate flood by setting twist_instance.suspended_at on that instance; the same flood will recur the moment any Airtable instance is unsuspended without this fix.
• The connector also never called integrations.channelSyncCompleted, so the connection card's "Syncing" indicator stayed stuck after the initial backfill completed.

What changes

• syncBatch now calls integrations.channelSyncCompleted(baseId) when the final table+page is exhausted, matching the canonical google-contacts pattern (connectors/google-contacts/src/google-contacts.ts:147). The runtime call is idempotent.
• reconcileComments takes an optional chainCount argument (back-compat for already-scheduled callbacks: undefined → fresh chain) and stores the previous fire time in reconcile_last_at_<baseId>. Healthy ~30-minute chains reset the depth to 0; chains arriving faster than RECONCILE_INTERVAL_MS - 60s accumulate the depth and bail with a console.warn once it crosses RECONCILE_FAST_CHAIN_CAP (1000). The cap is intentionally a defense-in-depth safety net — a connector with thousands of comments to backfill will still chain that long, since reconcile pages within a single execution and reschedules at 30-minute intervals.
• reconcileComments also calls channelSyncCompleted on its steady-state path so legacy instances whose backfill ran on the pre-completion version of syncBatch still clear the syncing indicator on the next reconcile tick.
• stopSync clears the new reconcile_last_at_<baseId> key.

Out of scope

Per the brief, platform-side fixes (per-twist queue isolation, Tasks.send rate limiting, auto-suspend on burst rate, dead-letter queues) are being investigated separately. This PR is the immediate-cause resolution for the Airtable connector itself.

Other connectors

I read this connector specifically and didn't audit others, but the brief asked to flag any similar self-chain patterns I noticed in passing — none jumped out from the imports/files I had to read. A pass over connectors that schedule their own follow-up work via runTask (gmail, google-calendar, slack, etc.) is worth doing as a separate sweep but is out of scope here.

Test plan

• Spot-check that a fresh sync of an Airtable base completes (initial backfill via syncBatch chain): connection card shows "Syncing" then clears once the final page is processed.
• Spot-check that an empty / already-synced base returns from reconcileComments after one call without queueing another faster than the 30-minute interval; reconcile_last_at_<baseId> is set; chainCount ratchets only under fast self-chaining.
• Confirm channelSyncCompleted is called when syncBatch exhausts all tables (the syncing indicator clears in the Flutter app).
• Confirm channelSyncCompleted is called on the first reconcile tick of a legacy instance whose initial backfill ran before this change (idempotent on the runtime side, so safe to call again).
• In a forced fast-chain scenario (manually invoke reconcileComments 1001 times in quick succession), the 1001st invocation logs Airtable reconcile: fast-chain cap reached, bailing out and stops the chain.

Rollout

After this PR merges, a plotday/core PR will need to bump the submodule pointer; plot deploy then rolls out the new connector version. The suspended Airtable instance (019dbbb2-abe1-7faf-a89e-5379b655295b) should not be unsuspended until that deploy lands.

🤖 Generated with Claude Code

[KrisBraun]

Summary

• reconcileComments self-reschedules on every invocation with no chain-depth guard. In production a single Airtable instance ran the chain fast enough to starve the shared run-production queue for hours, blocking sync recovery for 4 unrelated users. We've stopped the immediate flood by setting twist_instance.suspended_at on that instance; the same flood will recur the moment any Airtable instance is unsuspended without this fix.
• The connector also never called integrations.channelSyncCompleted, so the connection card's "Syncing" indicator stayed stuck after the initial backfill completed.

What changes

• syncBatch now calls integrations.channelSyncCompleted(baseId) when the final table+page is exhausted, matching the canonical google-contacts pattern (connectors/google-contacts/src/google-contacts.ts:147). The runtime call is idempotent.
• reconcileComments takes an optional chainCount argument (back-compat for already-scheduled callbacks: undefined → fresh chain) and stores the previous fire time in reconcile_last_at_<baseId>. Healthy ~30-minute chains reset the depth to 0; chains arriving faster than RECONCILE_INTERVAL_MS - 60s accumulate the depth and bail with a console.warn once it crosses RECONCILE_FAST_CHAIN_CAP (1000). The cap is intentionally a defense-in-depth safety net — a connector with thousands of comments to backfill will still chain that long, since reconcile pages within a single execution and reschedules at 30-minute intervals.
• reconcileComments also calls channelSyncCompleted on its steady-state path so legacy instances whose backfill ran on the pre-completion version of syncBatch still clear the syncing indicator on the next reconcile tick.
• stopSync clears the new reconcile_last_at_<baseId> key.

Out of scope

Per the brief, platform-side fixes (per-twist queue isolation, Tasks.send rate limiting, auto-suspend on burst rate, dead-letter queues) are being investigated separately. This PR is the immediate-cause resolution for the Airtable connector itself.

Other connectors

I read this connector specifically and didn't audit others, but the brief asked to flag any similar self-chain patterns I noticed in passing — none jumped out from the imports/files I had to read. A pass over connectors that schedule their own follow-up work via runTask (gmail, google-calendar, slack, etc.) is worth doing as a separate sweep but is out of scope here.

Test plan

• Spot-check that a fresh sync of an Airtable base completes (initial backfill via syncBatch chain): connection card shows "Syncing" then clears once the final page is processed.
• Spot-check that an empty / already-synced base returns from reconcileComments after one call without queueing another faster than the 30-minute interval; reconcile_last_at_<baseId> is set; chainCount ratchets only under fast self-chaining.
• Confirm channelSyncCompleted is called when syncBatch exhausts all tables (the syncing indicator clears in the Flutter app).
• Confirm channelSyncCompleted is called on the first reconcile tick of a legacy instance whose initial backfill ran before this change (idempotent on the runtime side, so safe to call again).
• In a forced fast-chain scenario (manually invoke reconcileComments 1001 times in quick succession), the 1001st invocation logs Airtable reconcile: fast-chain cap reached, bailing out and stops the chain.

Rollout

After this PR merges, a plotday/core PR will need to bump the submodule pointer; plot deploy then rolls out the new connector version. The suspended Airtable instance (019dbbb2-abe1-7faf-a89e-5379b655295b) should not be unsuspended until that deploy lands.

🤖 Generated with Claude Code

[KrisBraun]

Summary

• reconcileComments self-reschedules on every invocation with no chain-depth guard. In production a single Airtable instance ran the chain fast enough to starve the shared run-production queue for hours, blocking sync recovery for 4 unrelated users. We've stopped the immediate flood by setting twist_instance.suspended_at on that instance; the same flood will recur the moment any Airtable instance is unsuspended without this fix.
• The connector also never called integrations.channelSyncCompleted, so the connection card's "Syncing" indicator stayed stuck after the initial backfill completed.

What changes

• syncBatch now calls integrations.channelSyncCompleted(baseId) when the final table+page is exhausted, matching the canonical google-contacts pattern (connectors/google-contacts/src/google-contacts.ts:147). The runtime call is idempotent.
• reconcileComments takes an optional chainCount argument (back-compat for already-scheduled callbacks: undefined → fresh chain) and stores the previous fire time in reconcile_last_at_<baseId>. Healthy ~30-minute chains reset the depth to 0; chains arriving faster than RECONCILE_INTERVAL_MS - 60s accumulate the depth and bail with a console.warn once it crosses RECONCILE_FAST_CHAIN_CAP (1000). The cap is intentionally a defense-in-depth safety net — a connector with thousands of comments to backfill will still chain that long, since reconcile pages within a single execution and reschedules at 30-minute intervals.
• reconcileComments also calls channelSyncCompleted on its steady-state path so legacy instances whose backfill ran on the pre-completion version of syncBatch still clear the syncing indicator on the next reconcile tick.
• stopSync clears the new reconcile_last_at_<baseId> key.

Out of scope

Per the brief, platform-side fixes (per-twist queue isolation, Tasks.send rate limiting, auto-suspend on burst rate, dead-letter queues) are being investigated separately. This PR is the immediate-cause resolution for the Airtable connector itself.

Other connectors

I read this connector specifically and didn't audit others, but the brief asked to flag any similar self-chain patterns I noticed in passing — none jumped out from the imports/files I had to read. A pass over connectors that schedule their own follow-up work via runTask (gmail, google-calendar, slack, etc.) is worth doing as a separate sweep but is out of scope here.

Test plan

• Spot-check that a fresh sync of an Airtable base completes (initial backfill via syncBatch chain): connection card shows "Syncing" then clears once the final page is processed.
• Spot-check that an empty / already-synced base returns from reconcileComments after one call without queueing another faster than the 30-minute interval; reconcile_last_at_<baseId> is set; chainCount ratchets only under fast self-chaining.
• Confirm channelSyncCompleted is called when syncBatch exhausts all tables (the syncing indicator clears in the Flutter app).
• Confirm channelSyncCompleted is called on the first reconcile tick of a legacy instance whose initial backfill ran before this change (idempotent on the runtime side, so safe to call again).
• In a forced fast-chain scenario (manually invoke reconcileComments 1001 times in quick succession), the 1001st invocation logs Airtable reconcile: fast-chain cap reached, bailing out and stops the chain.

Rollout

After this PR merges, a plotday/core PR will need to bump the submodule pointer; plot deploy then rolls out the new connector version. The suspended Airtable instance (019dbbb2-abe1-7faf-a89e-5379b655295b) should not be unsuspended until that deploy lands.

🤖 Generated with Claude Code

[KrisBraun]

Summary

• reconcileComments self-reschedules on every invocation with no chain-depth guard. In production a single Airtable instance ran the chain fast enough to starve the shared run-production queue for hours, blocking sync recovery for 4 unrelated users. We've stopped the immediate flood by setting twist_instance.suspended_at on that instance; the same flood will recur the moment any Airtable instance is unsuspended without this fix.
• The connector also never called integrations.channelSyncCompleted, so the connection card's "Syncing" indicator stayed stuck after the initial backfill completed.

What changes

• syncBatch now calls integrations.channelSyncCompleted(baseId) when the final table+page is exhausted, matching the canonical google-contacts pattern (connectors/google-contacts/src/google-contacts.ts:147). The runtime call is idempotent.
• reconcileComments takes an optional chainCount argument (back-compat for already-scheduled callbacks: undefined → fresh chain) and stores the previous fire time in reconcile_last_at_<baseId>. Healthy ~30-minute chains reset the depth to 0; chains arriving faster than RECONCILE_INTERVAL_MS - 60s accumulate the depth and bail with a console.warn once it crosses RECONCILE_FAST_CHAIN_CAP (1000). The cap is intentionally a defense-in-depth safety net — a connector with thousands of comments to backfill will still chain that long, since reconcile pages within a single execution and reschedules at 30-minute intervals.
• reconcileComments also calls channelSyncCompleted on its steady-state path so legacy instances whose backfill ran on the pre-completion version of syncBatch still clear the syncing indicator on the next reconcile tick.
• stopSync clears the new reconcile_last_at_<baseId> key.

Out of scope

Per the brief, platform-side fixes (per-twist queue isolation, Tasks.send rate limiting, auto-suspend on burst rate, dead-letter queues) are being investigated separately. This PR is the immediate-cause resolution for the Airtable connector itself.

Other connectors

I read this connector specifically and didn't audit others, but the brief asked to flag any similar self-chain patterns I noticed in passing — none jumped out from the imports/files I had to read. A pass over connectors that schedule their own follow-up work via runTask (gmail, google-calendar, slack, etc.) is worth doing as a separate sweep but is out of scope here.

Test plan

• Spot-check that a fresh sync of an Airtable base completes (initial backfill via syncBatch chain): connection card shows "Syncing" then clears once the final page is processed.
• Spot-check that an empty / already-synced base returns from reconcileComments after one call without queueing another faster than the 30-minute interval; reconcile_last_at_<baseId> is set; chainCount ratchets only under fast self-chaining.
• Confirm channelSyncCompleted is called when syncBatch exhausts all tables (the syncing indicator clears in the Flutter app).
• Confirm channelSyncCompleted is called on the first reconcile tick of a legacy instance whose initial backfill ran before this change (idempotent on the runtime side, so safe to call again).
• In a forced fast-chain scenario (manually invoke reconcileComments 1001 times in quick succession), the 1001st invocation logs Airtable reconcile: fast-chain cap reached, bailing out and stops the chain.

Rollout

After this PR merges, a plotday/core PR will need to bump the submodule pointer; plot deploy then rolls out the new connector version. The suspended Airtable instance (019dbbb2-abe1-7faf-a89e-5379b655295b) should not be unsuspended until that deploy lands.

🤖 Generated with Claude Code

[KrisBraun]

Summary

• reconcileComments self-reschedules on every invocation with no chain-depth guard. In production a single Airtable instance ran the chain fast enough to starve the shared run-production queue for hours, blocking sync recovery for 4 unrelated users. We've stopped the immediate flood by setting twist_instance.suspended_at on that instance; the same flood will recur the moment any Airtable instance is unsuspended without this fix.
• The connector also never called integrations.channelSyncCompleted, so the connection card's "Syncing" indicator stayed stuck after the initial backfill completed.

What changes

• syncBatch now calls integrations.channelSyncCompleted(baseId) when the final table+page is exhausted, matching the canonical google-contacts pattern (connectors/google-contacts/src/google-contacts.ts:147). The runtime call is idempotent.
• reconcileComments takes an optional chainCount argument (back-compat for already-scheduled callbacks: undefined → fresh chain) and stores the previous fire time in reconcile_last_at_<baseId>. Healthy ~30-minute chains reset the depth to 0; chains arriving faster than RECONCILE_INTERVAL_MS - 60s accumulate the depth and bail with a console.warn once it crosses RECONCILE_FAST_CHAIN_CAP (1000). The cap is intentionally a defense-in-depth safety net — a connector with thousands of comments to backfill will still chain that long, since reconcile pages within a single execution and reschedules at 30-minute intervals.
• reconcileComments also calls channelSyncCompleted on its steady-state path so legacy instances whose backfill ran on the pre-completion version of syncBatch still clear the syncing indicator on the next reconcile tick.
• stopSync clears the new reconcile_last_at_<baseId> key.

Out of scope

Per the brief, platform-side fixes (per-twist queue isolation, Tasks.send rate limiting, auto-suspend on burst rate, dead-letter queues) are being investigated separately. This PR is the immediate-cause resolution for the Airtable connector itself.

Other connectors

I read this connector specifically and didn't audit others, but the brief asked to flag any similar self-chain patterns I noticed in passing — none jumped out from the imports/files I had to read. A pass over connectors that schedule their own follow-up work via runTask (gmail, google-calendar, slack, etc.) is worth doing as a separate sweep but is out of scope here.

Test plan

• Spot-check that a fresh sync of an Airtable base completes (initial backfill via syncBatch chain): connection card shows "Syncing" then clears once the final page is processed.
• Spot-check that an empty / already-synced base returns from reconcileComments after one call without queueing another faster than the 30-minute interval; reconcile_last_at_<baseId> is set; chainCount ratchets only under fast self-chaining.
• Confirm channelSyncCompleted is called when syncBatch exhausts all tables (the syncing indicator clears in the Flutter app).
• Confirm channelSyncCompleted is called on the first reconcile tick of a legacy instance whose initial backfill ran before this change (idempotent on the runtime side, so safe to call again).
• In a forced fast-chain scenario (manually invoke reconcileComments 1001 times in quick succession), the 1001st invocation logs Airtable reconcile: fast-chain cap reached, bailing out and stops the chain.

Rollout

After this PR merges, a plotday/core PR will need to bump the submodule pointer; plot deploy then rolls out the new connector version. The suspended Airtable instance (019dbbb2-abe1-7faf-a89e-5379b655295b) should not be unsuspended until that deploy lands.

🤖 Generated with Claude Code

[KrisBraun]

Summary

• reconcileComments self-reschedules on every invocation with no chain-depth guard. In production a single Airtable instance ran the chain fast enough to starve the shared run-production queue for hours, blocking sync recovery for 4 unrelated users. We've stopped the immediate flood by setting twist_instance.suspended_at on that instance; the same flood will recur the moment any Airtable instance is unsuspended without this fix.
• The connector also never called integrations.channelSyncCompleted, so the connection card's "Syncing" indicator stayed stuck after the initial backfill completed.

What changes

• syncBatch now calls integrations.channelSyncCompleted(baseId) when the final table+page is exhausted, matching the canonical google-contacts pattern (connectors/google-contacts/src/google-contacts.ts:147). The runtime call is idempotent.
• reconcileComments takes an optional chainCount argument (back-compat for already-scheduled callbacks: undefined → fresh chain) and stores the previous fire time in reconcile_last_at_<baseId>. Healthy ~30-minute chains reset the depth to 0; chains arriving faster than RECONCILE_INTERVAL_MS - 60s accumulate the depth and bail with a console.warn once it crosses RECONCILE_FAST_CHAIN_CAP (1000). The cap is intentionally a defense-in-depth safety net — a connector with thousands of comments to backfill will still chain that long, since reconcile pages within a single execution and reschedules at 30-minute intervals.
• reconcileComments also calls channelSyncCompleted on its steady-state path so legacy instances whose backfill ran on the pre-completion version of syncBatch still clear the syncing indicator on the next reconcile tick.
• stopSync clears the new reconcile_last_at_<baseId> key.

Out of scope

Per the brief, platform-side fixes (per-twist queue isolation, Tasks.send rate limiting, auto-suspend on burst rate, dead-letter queues) are being investigated separately. This PR is the immediate-cause resolution for the Airtable connector itself.

Other connectors

I read this connector specifically and didn't audit others, but the brief asked to flag any similar self-chain patterns I noticed in passing — none jumped out from the imports/files I had to read. A pass over connectors that schedule their own follow-up work via runTask (gmail, google-calendar, slack, etc.) is worth doing as a separate sweep but is out of scope here.

Test plan

• Spot-check that a fresh sync of an Airtable base completes (initial backfill via syncBatch chain): connection card shows "Syncing" then clears once the final page is processed.
• Spot-check that an empty / already-synced base returns from reconcileComments after one call without queueing another faster than the 30-minute interval; reconcile_last_at_<baseId> is set; chainCount ratchets only under fast self-chaining.
• Confirm channelSyncCompleted is called when syncBatch exhausts all tables (the syncing indicator clears in the Flutter app).
• Confirm channelSyncCompleted is called on the first reconcile tick of a legacy instance whose initial backfill ran before this change (idempotent on the runtime side, so safe to call again).
• In a forced fast-chain scenario (manually invoke reconcileComments 1001 times in quick succession), the 1001st invocation logs Airtable reconcile: fast-chain cap reached, bailing out and stops the chain.

Rollout

After this PR merges, a plotday/core PR will need to bump the submodule pointer; plot deploy then rolls out the new connector version. The suspended Airtable instance (019dbbb2-abe1-7faf-a89e-5379b655295b) should not be unsuspended until that deploy lands.

🤖 Generated with Claude Code

[KrisBraun]

Summary

• reconcileComments self-reschedules on every invocation with no chain-depth guard. In production a single Airtable instance ran the chain fast enough to starve the shared run-production queue for hours, blocking sync recovery for 4 unrelated users. We've stopped the immediate flood by setting twist_instance.suspended_at on that instance; the same flood will recur the moment any Airtable instance is unsuspended without this fix.
• The connector also never called integrations.channelSyncCompleted, so the connection card's "Syncing" indicator stayed stuck after the initial backfill completed.

What changes

• syncBatch now calls integrations.channelSyncCompleted(baseId) when the final table+page is exhausted, matching the canonical google-contacts pattern (connectors/google-contacts/src/google-contacts.ts:147). The runtime call is idempotent.
• reconcileComments takes an optional chainCount argument (back-compat for already-scheduled callbacks: undefined → fresh chain) and stores the previous fire time in reconcile_last_at_<baseId>. Healthy ~30-minute chains reset the depth to 0; chains arriving faster than RECONCILE_INTERVAL_MS - 60s accumulate the depth and bail with a console.warn once it crosses RECONCILE_FAST_CHAIN_CAP (1000). The cap is intentionally a defense-in-depth safety net — a connector with thousands of comments to backfill will still chain that long, since reconcile pages within a single execution and reschedules at 30-minute intervals.
• reconcileComments also calls channelSyncCompleted on its steady-state path so legacy instances whose backfill ran on the pre-completion version of syncBatch still clear the syncing indicator on the next reconcile tick.
• stopSync clears the new reconcile_last_at_<baseId> key.

Out of scope

Per the brief, platform-side fixes (per-twist queue isolation, Tasks.send rate limiting, auto-suspend on burst rate, dead-letter queues) are being investigated separately. This PR is the immediate-cause resolution for the Airtable connector itself.

Other connectors

I read this connector specifically and didn't audit others, but the brief asked to flag any similar self-chain patterns I noticed in passing — none jumped out from the imports/files I had to read. A pass over connectors that schedule their own follow-up work via runTask (gmail, google-calendar, slack, etc.) is worth doing as a separate sweep but is out of scope here.

Test plan

• Spot-check that a fresh sync of an Airtable base completes (initial backfill via syncBatch chain): connection card shows "Syncing" then clears once the final page is processed.
• Spot-check that an empty / already-synced base returns from reconcileComments after one call without queueing another faster than the 30-minute interval; reconcile_last_at_<baseId> is set; chainCount ratchets only under fast self-chaining.
• Confirm channelSyncCompleted is called when syncBatch exhausts all tables (the syncing indicator clears in the Flutter app).
• Confirm channelSyncCompleted is called on the first reconcile tick of a legacy instance whose initial backfill ran before this change (idempotent on the runtime side, so safe to call again).
• In a forced fast-chain scenario (manually invoke reconcileComments 1001 times in quick succession), the 1001st invocation logs Airtable reconcile: fast-chain cap reached, bailing out and stops the chain.

Rollout

After this PR merges, a plotday/core PR will need to bump the submodule pointer; plot deploy then rolls out the new connector version. The suspended Airtable instance (019dbbb2-abe1-7faf-a89e-5379b655295b) should not be unsuspended until that deploy lands.

🤖 Generated with Claude Code

[KrisBraun]

Summary

• reconcileComments self-reschedules on every invocation with no chain-depth guard. In production a single Airtable instance ran the chain fast enough to starve the shared run-production queue for hours, blocking sync recovery for 4 unrelated users. We've stopped the immediate flood by setting twist_instance.suspended_at on that instance; the same flood will recur the moment any Airtable instance is unsuspended without this fix.
• The connector also never called integrations.channelSyncCompleted, so the connection card's "Syncing" indicator stayed stuck after the initial backfill completed.

What changes

• syncBatch now calls integrations.channelSyncCompleted(baseId) when the final table+page is exhausted, matching the canonical google-contacts pattern (connectors/google-contacts/src/google-contacts.ts:147). The runtime call is idempotent.
• reconcileComments takes an optional chainCount argument (back-compat for already-scheduled callbacks: undefined → fresh chain) and stores the previous fire time in reconcile_last_at_<baseId>. Healthy ~30-minute chains reset the depth to 0; chains arriving faster than RECONCILE_INTERVAL_MS - 60s accumulate the depth and bail with a console.warn once it crosses RECONCILE_FAST_CHAIN_CAP (1000). The cap is intentionally a defense-in-depth safety net — a connector with thousands of comments to backfill will still chain that long, since reconcile pages within a single execution and reschedules at 30-minute intervals.
• reconcileComments also calls channelSyncCompleted on its steady-state path so legacy instances whose backfill ran on the pre-completion version of syncBatch still clear the syncing indicator on the next reconcile tick.
• stopSync clears the new reconcile_last_at_<baseId> key.

Out of scope

Per the brief, platform-side fixes (per-twist queue isolation, Tasks.send rate limiting, auto-suspend on burst rate, dead-letter queues) are being investigated separately. This PR is the immediate-cause resolution for the Airtable connector itself.

Other connectors

I read this connector specifically and didn't audit others, but the brief asked to flag any similar self-chain patterns I noticed in passing — none jumped out from the imports/files I had to read. A pass over connectors that schedule their own follow-up work via runTask (gmail, google-calendar, slack, etc.) is worth doing as a separate sweep but is out of scope here.

Test plan

• Spot-check that a fresh sync of an Airtable base completes (initial backfill via syncBatch chain): connection card shows "Syncing" then clears once the final page is processed.
• Spot-check that an empty / already-synced base returns from reconcileComments after one call without queueing another faster than the 30-minute interval; reconcile_last_at_<baseId> is set; chainCount ratchets only under fast self-chaining.
• Confirm channelSyncCompleted is called when syncBatch exhausts all tables (the syncing indicator clears in the Flutter app).
• Confirm channelSyncCompleted is called on the first reconcile tick of a legacy instance whose initial backfill ran before this change (idempotent on the runtime side, so safe to call again).
• In a forced fast-chain scenario (manually invoke reconcileComments 1001 times in quick succession), the 1001st invocation logs Airtable reconcile: fast-chain cap reached, bailing out and stops the chain.

Rollout

After this PR merges, a plotday/core PR will need to bump the submodule pointer; plot deploy then rolls out the new connector version. The suspended Airtable instance (019dbbb2-abe1-7faf-a89e-5379b655295b) should not be unsuspended until that deploy lands.

🤖 Generated with Claude Code