Skip to content

Conversation

@patriknw
Copy link
Contributor

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
Member

@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
Member

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
Contributor

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.

4 participants