fix(traffic): connect auto-creates the traffic-sync schedule so a new source actually syncs#679
Merged
Merged
Conversation
… source actually syncs A freshly connected Vercel source seeded `lastSyncedAt = NOW` (#634) but nothing advanced that watermark, because `traffic connect` never created the traffic-sync schedule. An unscheduled source's watermark drifts, and the next sync (dashboard- or manually-triggered) pulls an unbounded window that wedges: the other half of the first-sync trap #634 thought it closed. Operators had to know to run `cnry schedule set --kind traffic-sync` by hand, and a source that looked "connected" silently ingested nothing. Connect now creates the project's traffic-sync schedule (`*/30 * * * *`, idempotent via the unique `(project, kind)` index) in the same transaction as the source upsert, and registers it with the live scheduler via `onScheduleUpdated`. Seeding `lastSyncedAt = NOW` only keeps the FIRST window tight; the schedule is what keeps the watermark from drifting. Reconnects, and projects that already have a traffic-sync schedule, are left untouched. - Thread `onScheduleUpdated` into `TrafficRoutesOptions`, wired from `ApiRoutesOptions`. - Tests: schedule created + bound to the source, `onScheduleUpdated` fired, idempotent on reconnect. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A freshly connected Vercel traffic source seeds
lastSyncedAt = NOW(#634), buttraffic connectnever creates thetraffic-syncschedule that consumes it. With no schedule, the watermark never advances, so the next sync (dashboard- or manually-triggered) pulls an unbounded window and wedges — the other half of the first-sync trap #634 thought it closed. The source reads "connected" but ingests nothing, and recovery requires the operator to know aboutcnry schedule set --kind traffic-syncplustraffic reset --advance-to-now.Fix
traffic connectnow creates the project'straffic-syncschedule in the same transaction as the source upsert, and registers it with the live scheduler viaonScheduleUpdated:*/30 * * * *(retunable viaschedule set).traffic-syncschedule, is left untouched — aligns with the unique(project, kind)index.lastSyncedAt = NOWkeeps only the FIRST window tight; the schedule is what keeps the watermark from drifting on later triggers.No API surface change (no new endpoint/field), so no SDK regen.
Tests
packages/api-routes/test/traffic.test.ts(api-routes project, 96 passing):traffic-syncschedule bound to the new source (*/30, enabled, UTC)onScheduleUpdated('upsert', …, 'traffic-sync')typecheck+lintclean. Patch bump 4.69.2 → 4.69.3.Follow-ups (not in this PR)
traffic-syncschedule when a source is disconnected/archived.🤖 Generated with Claude Code