Repository navigation
fix(core): dedupe chain events (CORE-08) - #199
Merged
Merged
Conversation
…Id) (#60) Every ChainEvent append now goes through recordChainEvents (store.ts): an event whose key is already stored is skipped, first recording wins, events without a txHash are never collapsed. A milestone's escrow refund is booked in repayments once, even when two writers reconcile the same ambiguous LoanPay.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Last open item of #60 (CORE-08): chain events were not deduplicated (
packages/core/API.mdsaid so). Atomic writes, the cross-process lock and the encrypted preimage store already landed in #140.Key: (txHash, kind, projectId, milestoneId), hash compared case-insensitively. Not the hash alone: one tx can back several events that are all real history (another kind, another project's view of a shared tx, or one hash per milestone), so only an exact repeat of the same fact collapses. Today every event has its own hash: Batch escrows use their inner EscrowCreate hashes, and
precedingtxs are not recorded. The wider key keeps it that way if that ever changes. First recording wins: a later reconcile of the same tx (result: "reconciled_loan_repaid"/"reconciled_escrow_consumed") does not replace it. Events without a txHash are never collapsed.Where:
recordChainEvents(db, events)instore.tsis now the only way core appends a ChainEvent: all 21 sites inservice.tsand the prestage import. Routes still return the events from their own call.Found while testing: two writers on one FileStore (the keeper process and the server) can both reconcile the same ambiguous refund LoanPay. Before this PR that recorded the event twice and also booked the repayment twice.
commitRefundnow books a milestone's escrow refund once.Tests (
test/event-dedupe.test.ts, plus one inprestage-import.test.ts):escrow_createdevents plus oneloan_setmainwith 2 events)pnpm -r typecheck && pnpm -r testgreen (core 158 tests).Closes #60