Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: updateTimestampOffset #1102

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

patriknw
Copy link
Member

Just an idea so far...

For the Durable State change events it's possible that you start out with ordinary Durable State and then enable change events later. Meaning that there will missing events and offsets for earlier sequence numbers (revisions). The offset validation will reject them and the projection will be stuck.

One way would be to populate the offset store with known "starting points" via the projection management api.

In general, we are lacking projection management for timestamp offsets, because they are not a single value.

Copy link
Contributor

@pvlugter pvlugter left a comment

Choose a reason for hiding this comment

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

Looks useful.

* This can be useful if the projection was stuck with errors on a specific offset and should skip
* that offset and continue with next.
*
* Another use case is to populate the offset store with know starting points when enabling change events
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
* Another use case is to populate the offset store with know starting points when enabling change events
* Another use case is to populate the offset store with known starting points when enabling change events

}

retry(() => askSetTimestampOffset())
}
Copy link
Member

Choose a reason for hiding this comment

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

How would one handling starting a new projection from the offsets, hold back the consumer until the response comes back from this API, because it would start consuming from start as soon as it has started executing, right?

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.

3 participants