Repository navigation
fix(mock): return paymentHash from /decodeinvoice (#67) - #68
Merged
Merged
Conversation
added 2 commits
October 5, 2026 20:06
…/incoming
The mock's /decodeinvoice answered only amount and description, so
payment-adapter 0.17.2's RECEIVE lookup failed on every quote and the mint
returned 500s. It now returns the issued hash for its own invoices, the p
field for other BOLT11 strings, or a deterministic SHA-256 otherwise, and
serves GET /payments/incoming/{hash}, which the adapter calls next.
DecodeInvoiceResponse no longer @JsonIgnore's paymentHash, which made the
client drop it even when phoenixd sent it, and ignores unknown fields.
Fixes #67
Qodana Community for JVM5 new problems were found
☁️ View the detailed Qodana report Contact Qodana teamContact us at qodana-support@jetbrains.com
|
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.
Fixes #67.
Problem
Staging's phoenixd-mock
/decodeinvoicereturned{"amount":1000,"description":"1 Blockaccino"}with nopaymentHash. payment-adapter 0.17.2 (PhoenixdGateway.askPhoenixd) decodes each RECEIVE quote's invoice, readsgetPaymentHash(), and callsGET /payments/incoming/{hash}. With no hash it throwsphoenixd_lookup_failed, the mint answers 500, and MintCircuitBreakerFlapping fires on every e2e run.There was a second cause on the client side.
DecodeInvoiceResponse.paymentHashwas@JsonIgnore, so Jackson dropped the field even when the server sent it (checked against the published 0.3.0 jar:hash=null). The mock also had no/payments/incomingroute.Fix
/decodeinvoicereturns phoenixd's shape:chain, amount, paymentHash, description, minFinalCltvExpiryDelta, timestampSeconds. The hash is chosen in this order: the hash the mock issued with the invoice, then the BOLT11pfield, then the SHA-256 of the string, so the answer is always deterministic.pfield of the invoice.GET /payments/incoming/{hash}returnspaymentHash, isPaid, receivedSat, externalId, ...and gives 404 for an unknown hash. Those are the fieldsIncomingPaymentResponsereads in the adapter.paymentHashis deserialized, and the class sets@JsonIgnoreProperties(ignoreUnknown = true).Tests
Each test failed before the fix and passes after it. In
phoenixd-model(1) andphoenixd-mock(4): issued hash round-trip, the BOLT11 spec vector'spfield, deterministic hash for an unknown string, decode then incoming lookup, and DTO deserialization.mvn verifypasses on model, rest, base, and mock. phoenixd-test could not bind port 9740 locally because a phoenixd was already running there, so CI covers that module.Note: payment-adapter still pins phoenixd-java 0.3.0. Against real phoenixd, its client drops
paymentHashuntil it bumps to 0.3.3.