5ec2c1cb - UMA-On-Chain-Settlement am OpenCryptoPay-Callback abdecken

[joshuakrueger-dfx]

Offene ToDos (nicht aus diesem Branch schließbar)

• Companion im Backend mergen, bevor dieser PR grün laufen kann: DFXswiss/backend#5379 liefert sowohl die UMA-Parameter am Callback als auch die Auswertung von PAYMENT_LOC_MIN_FEE. Warum nicht von hier: anderes Repo. Wer: wer den Backend-PR reviewt.

EN: Adds end-to-end coverage for the UMA on-chain settlement flow that DFXswiss/backend#5379 introduces at the OpenCryptoPay LNURL-pay callback. Four API-only cases, no browser. Also sets PAYMENT_LOC_MIN_FEE=0 in the stack's API env, without which no payment-link quote gets transfer amounts under ENVIRONMENT=loc.

DE: Deckt den UMA-On-Chain-Fluss ab, den DFXswiss/backend#5379 am OpenCryptoPay-LNURL-Callback einführt. Vier reine API-Fälle, kein Browser. Setzt zusätzlich PAYMENT_LOC_MIN_FEE=0 in der API-Env des Stacks — ohne die entstehen unter ENVIRONMENT=loc gar keine Transferbeträge.

Not symptom-driven: Keine Störungsmeldung. Anlass ist eine neu gebaute Backend-Funktion, die auf Schicht 3 noch keinen Beleg hat, und eine dabei gemessene Lücke der Harness.

Scale: Betrifft die gesamte E2E-Abdeckung des OpenCryptoPay-Zahlungsflusses, die bisher bei null lag: Kein bestehender Spec ruft /v1/lnurlp/:id erfolgreich auf — die vorhandenen Payment-Link-Fälle prüfen Fehlerpfade, und ein Frontend-Fall erwartet ausdrücklich „NO PAYMENT ACTIVE" mit der Begründung, dass unter ENVIRONMENT=loc kein Live-Pricing verfügbar ist.

Smaller fix considered: Nur Unit-Tests im Backend — insufficient because die beweisen die Weiche und die Betragsrechnung, aber nicht, dass eine echte API mit echter Postgres am Ende eine ethereum:-URI mit dem richtigen Betrag ausliefert. Genau diese Kette ist der Zweck der Harness (docs/test-architecture.md im Backend: ein Fehlermodus wird auf der niedrigsten Schicht getestet, die ihn ausdrücken kann; die Kette durch API und DB gehört hierher).

Details

Die Fälle

Fall	Prüft
Kasse ohne PayToAddress	Callback mit UMA-Parametern liefert weiterhin eine BOLT11-Invoice — der Regressionsfall
Kasse mit PayToAddress	Callback liefert blockchain: "Ethereum" und eine ethereum:-URI, deren Betrag der Transferbetrag der Quote in Asset-Einheiten ist, nicht der gesendete Millisatoshi-Wert
payRequest	settlementOptions erscheint nur bei einer Kasse mit PayToAddress
Vorrang	Werden method/asset mitgesendet, gewinnen sie, und die UMA-Parameter bleiben wirkungslos

Alles reine fetch-Fälle nach dem Muster von specs/fixtures/auth.ts (signatureLogin) und specs/fixtures/factories.ts (createPaymentLink); keine page-Fixture, kein Browser. Die Kassen-Konfiguration wird per SQL gesetzt, weil die Factory keine standards annimmt.

Warum die Env-Variable hierher gehört

getMinFee gibt unter ENVIRONMENT=loc undefined zurück — bewusst, weil es lokal keine Node-Verbindungen gibt und der Guard sonst in Timeouts liefe. Die Folge trifft die ganze Kette: createTransferAmount lässt die Asset-Liste leer, createTransferAmounts nimmt den Eintrag nicht auf, und createPayRequest findet keinen BTC-Transferbetrag. Der Companion-PR macht diesen Floor konfigurierbar, ohne den Guard zu entfernen; hier wird er auf 0 gesetzt.

Bekannte Grenze der Harness

Der Lightning-Fall lässt sich in dieser Umgebung nicht grün bekommen: createPaymentLink legt eine synthetische Deposit-Adresse e2e-ln-<tag> an, die keine LNURL ist, und der Callback antwortet 400 "Deposit LNURLp Address not found"; der loc-HTTP-Mock für LNBits liefert {mock:true} ohne payment_request. Der Fall bleibt im Spec, weil er den Regressionspfad beschreibt, den das Backend schützt — er ist aber eine zweite, eigenständige Harness-Grenze und in diesem PR nicht behoben. Die drei EVM-Fälle laufen durch.