Skip to content

An opaque checkpoint position instead of a u64 #184

Description

@kennywillbe

The problem

Source positions reach the engine as an opaque u64 token. That fits an LSN and a GTID-derived offset, but not every change stream: SQL Server's LSN is binary(10) (80 bits), MongoDB resume tokens are strings. Any source whose position does not fit cannot be written without touching core first — and if one is written around the limit, every later installation inherits a migration.

Proposed behaviour

Generalise the position token to an opaque byte string end to end: the core checkpoint type, the comparison the engine needs (ordering stays the source's business), and the checkpoint document format in every target. One epic, not one PR, because the stored format changes: the sinks must read an existing u64 checkpoint and write the new form, so a live installation restarts without losing its position. Proven by the failover probe and the kill -9 e2e sections in all three targets.

What you tried instead

Deferring until the first non-u64 source: that turns a planned migration into a forced one, written under pressure inside an unrelated source PR.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions