-
Notifications
You must be signed in to change notification settings - Fork 87
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
Create EventSource and EventSink handles #1267
Create EventSource and EventSink handles #1267
Conversation
cardenaso11
commented
Jan 22, 2024
- CHANGELOG updated or not needed
- Documentation updated or not needed
- Haddocks updated or not needed
- No new TODOs introduced or explained herafter
@cardenaso11 Hey it's great to see you started work on implementing ADR29! I'm a bit surprised though that you would update the Happy to have an alignment chat on discord or so about this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We discussed the approach and also drafted the call sites here: 4a281ce
f23b790
to
fe72281
Compare
4208eaf
to
067edec
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wasn't sure if this is ready to review already, but left some comments nontheless.
I think you would benefit a lot from not changing the HeadLogic and API Server as this results in a lot of noise and is a too big of a step (see my "Must" comments)
95ea20a
to
599b405
Compare
e379909
to
c92df27
Compare
…entSink.\n\nIt's not clear yet if we can have the statechange ID in the StateChanged type as a substitute for tracking the current stateChangeID in the node\nBut for now it works to get the node's stateChangedID into the disk-persistence eventSink's putEvent', where we can compare it against the last persisted stateChange\nThis works for the particular disk-based eventSink where we *do have* exactly-once, but in ex kinesis poc or redis or something, it can be the key for at-least-once dict lint
…to minimize first PR
We can define an event source and event sink from the PersistenceIncremental.
Having a dedicated module allows easier import in forks of hydra and hopefully serves as a better extension points (with less breakage).
We kept the EventSource/EventSink very abstract to make implementations not realy on the internas of the actual data type used. However, an event source / sink will need at least identify individual events to tell them apart, e.g. to deduplicate them in memory.
Current idea: Keep notes where extensions are possible so we don't change things by accident breaking external/custom code of users.
We do not want to update this module (yet) with a different means for persistence.
c92df27
to
8a00c06
Compare
By making the step-wise construction of HydraNode monadic (although not specifically needed) we can simplify call-sites in the NodeSpec.
This is unfortunately very "white-boxy" and the testing code needs to know that the generated events must be using parameters consistent with the environment. The alternative would be to move checkHeadState outside of hydrate, but then 'WetHydraNode's can exist without this check happening.
2a1d836
to
644d232
Compare
644d232
to
fa7d970
Compare
Superseded by #1351 |