Skip to content

Conversation

simolus3
Copy link
Contributor

When deploying new sync rules, the service will re-index everything from a consistent snapshot. Since it re-uses existing bucket ids for this, this means that oplog history checksums within a bucket change too. This is bad for clients, which may download new data ontop of their old oplog without deleting it right away. That increases the sync time (because clients have to wait for a consistent snapshot only to realize that their checksums are off and restart) and can be confusing (because sync progress appears to reach 1.0 before restarting).

A backwards-incompatible change is to encode the id of persisted sync rules in the created bucket ids. This means that every redeploy leads to different bucket ids, causing clients to drop their old buckets instead of trying to consider that data. Since this format would break existing deployments, it's only enabled for sync streams or with an opt-in.

Copy link

changeset-bot bot commented Aug 21, 2025

🦋 Changeset detected

Latest commit: 5ee6c7b

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 17 packages
Name Type
@powersync/service-sync-rules Minor
@powersync/service-image Minor
@powersync/service-jpgwire Patch
@powersync/service-core-tests Patch
@powersync/service-core Minor
@powersync/lib-services-framework Patch
@powersync/service-module-mongodb-storage Patch
@powersync/service-module-mongodb Patch
@powersync/service-module-mysql Patch
@powersync/service-module-postgres-storage Patch
@powersync/service-module-postgres Patch
@powersync/lib-service-postgres Patch
@powersync/service-module-core Patch
test-client Patch
@powersync/service-rsocket-router Patch
@powersync/lib-service-mongodb Patch
@powersync/service-schema Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@rkistner
Copy link
Contributor

We could also potentially enable this for any new sync rules deploy - in that case we'd just need to persist the state in the sync_rules storage collection/table. But not sure if that's actually worth the extra implementation effort - the approach here would eventually cover the majority of cases as we encourage users to switch to sync streams or the new defaults.

@simolus3 simolus3 force-pushed the fix-timestamp-representation branch from da0954b to d9a8f65 Compare August 21, 2025 08:59
@simolus3 simolus3 force-pushed the sync-rule-id-in-bucket-ids branch from 4eeb885 to d91c383 Compare August 21, 2025 10:13
@simolus3 simolus3 marked this pull request as ready for review August 21, 2025 11:27
@simolus3 simolus3 force-pushed the fix-timestamp-representation branch from 32c548a to 1ce5d65 Compare August 22, 2025 15:48
Base automatically changed from fix-timestamp-representation to main August 25, 2025 09:27
@simolus3 simolus3 force-pushed the sync-rule-id-in-bucket-ids branch from 3f41d60 to db8eff4 Compare August 27, 2025 07:48
rkistner
rkistner previously approved these changes Aug 27, 2025
@simolus3 simolus3 force-pushed the sync-rule-id-in-bucket-ids branch from e26d1f5 to 5ee6c7b Compare August 27, 2025 08:18
@simolus3 simolus3 requested a review from rkistner August 27, 2025 08:29
@simolus3 simolus3 merged commit 98c6bef into main Aug 27, 2025
21 checks passed
@simolus3 simolus3 deleted the sync-rule-id-in-bucket-ids branch August 27, 2025 09:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants