Carry the publish-time journey id on ProposalMetadata - #35
Conversation
|
The latest Buf updates on your PR. Results from workflow Buf CI / buf (pull_request).
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Included review availability: 2 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 5 reviews per hour. 📜 Recent review details⏰ Context from checks skipped due to timeout. (1)
WalkthroughThe ChangesProposal metadata
Estimated code review effort: 1 (Trivial) | ~2 minutes Merge Risk: ⚪ Minimal · up to This PR adds the publish-time journey ID without changing existing fields or their meanings; no actionable merge-blocking risk remains after normal checks and review. 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 Buf (1.72.0)proto/splitsecure/proposals/v1/proposal_metadata.protofatal: unable to access 'https://github.com/splitsecure/apis.git/': Failed to connect to github.com port 443 via 127.0.0.1 after 0 ms: Could not connect to server Comment |
840adc7 to
b314784
Compare
Problem
Nothing on the wire says which journey a proposal belongs to, and a client cannot work it out.
ProposalMetadata.proposal_iddoes not answer it: GetEvents echoes the SHA3-512 of the execution context, while GetProposal overwrites the same field with the flow id. Even given both, reconstruction is impossible in principle - the journey kind depends on what the mint carried (a roll-forward flow, an invitation lobby, or the proposal itself), and the proposal kind is addressed by a hash the client never holds.Consumers that need to link to a request have been rebuilding the id from whichever id they had, which produces a dead link whenever the guess is wrong.
Fix
Add
journey_idtoProposalMetadata, carrying the id the server already stamps at publish time. Field 10, additive.Validation
buf lintclean.buf breakingagainstmainclean. Go and TS regenerated withbufgen.sh.Impact
Additive: no existing field changes meaning or number. Consumers can delete their client-side reconstruction once the server populates it.