fix(knowledge): store connector sync schedules at millisecond precision - #7966
Conversation
The scheduler round-trips next_member_sync_at through a JavaScript Date and claims the run by matching the value back exactly. Date carries milliseconds while PostgreSQL stored microseconds, so a schedule written in SQL rather than by the application became unmatchable the moment it landed on a fractional millisecond: the connector stayed permanently due, every claim was refused, and its members never synced. Narrow both connector schedule columns to timestamp(3) so the two ends compare the same value. The rewrite also rounds the stored values, so an already-wedged row recovers on the next scheduler tick. Also stop the claim diagnosis from asserting a queued run it cannot see — it now reads the lock token and says so plainly when no condition explains the refusal, which is what let this hide as ordinary contention.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
No issues found across 9 files
Confidence score: 5/5
- Automated review surfaced no issues in the provided summaries.
- No files require special attention.
Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.
Re-trigger cubic
…rows Scope the column-precision query to the test schema. It matched on table name alone, so in CI — where the database already holds the migrated public table — it saw four columns instead of two and failed. A local run passed because the throwaway schema was the only place that table existed. Write the sub-millisecond schedule before applying the migration rather than after, so the test pins the rewrite rounding an already-wedged row, not just the narrowed column refusing new ones. Without the migration it now fails on exactly that claim.
|
@cubic-dev-ai review this PR |
@waleedlatif1 I have started the AI code review. It will take a few minutes to complete. |
There was a problem hiding this comment.
No issues found across 9 files
Confidence score: 5/5
- Automated review surfaced no issues in the provided summaries.
- No files require special attention.
Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.
Re-trigger cubic
This branch was successfully deployed
1 participant
Summary
next_member_sync_atinto a JavaScriptDateand claims the run with an equality match on that value.Datecarries milliseconds; PostgreSQL stored microseconds. A schedule written in SQL rather than by the application became permanently unmatchable once it landed on a fractional millisecond — the connector stayed due forever, every claim was refused, and its members never synced.next_member_sync_atandnext_sync_attotimestamp(3)so both ends compare the same value. Both columns move in oneALTER TABLEso the rewrite is a single pass. The rewrite rounds the stored values, so an already-wedged row recovers on the next scheduler tick — no backfill needed.knowledge_connector_member.next_attempt_atis written by the same backfill but is only ever range-compared, never claimed by equality, so it is deliberately left alone. The migration header says so.describeUnacceptedMemberSyncfrom asserting "a member sync is already queued or running" when it cannot see one. It now reads the lock token and reports plainly when no condition explains the refusal — the misleading fallback is what let this read as ordinary contention.Type of Change
Testing
check:migrations✓,lint✓,check:audits(46) ✓,docs-manifest:check✓,type-check(apps/sim + packages/db) ✓. Both migration-contract suites pass against a local PostgreSQL; the new test was confirmed to fail with the migration stubbed out.member-queueandqueueunit suites pass (51).Checklist