feat: preserve method-specific receipt extension fields#612
Open
IkerAlus wants to merge 1 commit into
Open
Conversation
The core spec's Payment-Receipt section allows method specifications to define additional receipt fields. Parse receipts with a loose schema so unknown fields survive from/serialize/deserialize round trips instead of being stripped, keeping the exported Receipt type unchanged (base fields only, no index signature).
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
1 participant
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.
The core spec's Payment-Receipt section allows method specifications to define additional receipt fields, but
Receipt.Schemastrips unknown fields on parse. Hence servers can't emit them (Receipt.from) and no mppx client can read them (Receipt.fromResponse, the fetch client, the CLI).This PR loosens the runtime schema while keeping the exported
Receipttype unchanged:Motivation: the new
nearintentsmethod (cross-chain settlement) requiresoriginTxHashandchallengeIdin its receipt (a cross-chain payment has two legs, and reference only carries the destination-side tx). Our plan is to ship the method as a standalone package per the custom-payment-methods guide. This is the one core touchpoint a package can't work around, because the stripping happens on the client side.Also, the repo already assumes extended receipts in places, the CLI renders arbitrary receipt fields (and explorer-links txHash), and tempo session receipts carry channelId / acceptedCumulative / spent. This aligns the core schema with that.
Backward compatible: existing methods emit unchanged receipts; older clients strip extras exactly as today. Tests added for preservation, round-trip, and validation-with-extensions; changeset included.