Skip to content

Add implementation of returnable last_seq - #800

Draft
veronika-alraheem wants to merge 1 commit into
mainfrom
1284-last-seq
Draft

Add implementation of returnable last_seq#800
veronika-alraheem wants to merge 1 commit into
mainfrom
1284-last-seq

Conversation

@veronika-alraheem

Copy link
Copy Markdown

PR summary

Add implementation of returnable last_seq for safe checkpoint management.

Fixes: i1284

PR Checklist

Please make sure that your PR fulfills the following requirements:

  • The commit message follows the
    Angular Commit Message Guidelines.
  • Tests for the changes have been added (for bug fixes / features)
  • Docs have been added / updated (for bug fixes / features)

PR Type

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • New tests
  • Build/CI related changes
  • Documentation content changes
  • Other (please describe)

What is the current behavior?

The ChangesFollower API streams changes as individual ChangesResultItem objects but provides no mechanism for users to determine a safe sequence ID to use as a checkpoint. For heavily filtered feeds where pages return empty results, users have no way to advance their checkpoint even though the feed has progressed internally.

What is the new behavior?

A new public method getLastSeqNewerThan(lastPersistedSeqId) is added to ChangesFollower. After fully processing a ChangesResultItem, users can call this method with the item's seq value to obtain the most recent sequence ID that is safe to persist as a checkpoint.

The method advances past any empty pages (e.g. from heavily filtered feeds) that the follower has seen since the given sequence ID, returning the furthest safe checkpoint available at that point.

Does this PR introduce a breaking change?

  • Yes
  • No

if entry.entryType == seqEntryRow {
break
}
result = *entry.seq

@ricellis ricellis Aug 28, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be defensive with the != nil check in the same way as in the following else if.
I think the only way it could be nil is if a page was returned with a nil last_seq - I don't think that is very likely, but I'd rather not find via the nil de-reference panic if it ever does happen.

In the case that it did we should probably just skip it, so that we can return the furthest possible (if there are pages with non-null last_seq available) or the previous result that was the furthest one we reached before finding the nil.

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