stack/getpaid 2 50 bullnym fiat foundation - #218
Draft
BullishNode wants to merge 9 commits into
Draft
Conversation
Consume the authoritative top-level settlement_kind instead of deriving the classification from field presence, cross-check the tagged detail kind, and enforce the per-leg contract invariants (positive amounts, the pinned currency whitelist, non-nil UUID order ids, the amount_minor settled-only rule, the liquid-only Bitcoin network, and the pending/settled/problem Bitcoin-leg statuses). Any inconsistency fails closed to the unavailable projection and an absent settlement_kind maps to the no-data state, never to Bitcoin. Route the local Bull Bitcoin account check through the exchange API-key repository boundary instead of the datasource, and add a byte-identical server fixture conformance test plus the full fail-closed parse matrix.
…odes to server Two staging-integration contract fixes against Bullnym PRs #197/#198: - getFiatSettlementConfiguration now sends the required `version` query parameter. The server's ConfigurationQuery rejects a read without it (HTTP 400); the set path already carries version in its body, which is why only the read was affected. - Credential error codes aligned to the server's wire names BULL_BITCOIN_CREDENTIAL_REQUIRED / BULL_BITCOIN_CREDENTIAL_INVALID (were FIAT_CREDENTIAL_*), so a missing/invalid scoped credential maps to credentialProblem (Reconnect) instead of an unexpected failure. KYC (FIAT_CONVERSION_KYC_REQUIRED) is unchanged. Fake client, contract and mapping tests updated to the same strings.
Restoring from backup previously did not recreate the bip85 product wallets recorded in the keychain manifest (e.g. Donation Page index 102 and POS index 103): the mnemonic-recover flow kicked off remote manifest recovery fire-and-forget, so WalletBloc loaded the inventory before the wallets were materialized, and the RecoverBull vault-restore flow never ran manifest recovery at all. - Await remote manifest recovery in the onboarding recover flow before emitting success (success drives WalletStarted), so restored manifest wallets exist on the first inventory load. The onboarding wrapper now exposes its Future instead of firing and forgetting. - Run the same manifest recovery after a RecoverBull vault restore, passing the restored default wallet ids so metadata recovery covers them, and only start the wallet once recovery has returned. - Bound the whole recovery to a 60s total budget, enforced cooperatively: the remote fetch is timed out against the remaining budget and the wallet materialization loop checks the deadline before deriving each wallet, so an overrun can never keep creating wallets in the background. A hard ceiling maps a genuinely hung leaf call to a timedOut outcome. On no manifest / unavailable / timeout the defaults are kept and the flow continues silently. - Relocate the recovery entrypoint to the remote_keychain_recovery feature so both onboarding and RecoverBull drive one re-invocable, error-swallowing usecase. Existing entry validation (reservation, path, fingerprint, network, script, wallet id) and idempotency are preserved: invalid entries fail closed, repeats report already-present and create no duplicates.
…k onboarding Review follow-ups to the manifest-restoration batch. - The optional recovery wrapper now catches every error (not just Exception). Onboarding and RecoverBull await it before continuing, so a bug anywhere in the recovery graph (a TypeError/StateError) must never block or fail onboarding or vault restore; the defaults already exist and we degrade silently. - Restoration is read-only with respect to Bullnym products. The DG-3 liveness check now queries Lightning Address with allowReregister:false, so a lapsed-but-known legacy registration is flagged for user-driven reactivation instead of being silently re-registered. Recovery never writes to a product (master-doc contract #4); the re-register capability itself is retained for the dashboard/product-screen flows. - Documented the hard-timeout bound: when the ceiling fires the inner future keeps running detached, but the wallet loop's cooperative deadline gate stops it before the next materialization, so at most one in-flight (idempotent, recorded) wallet can still complete. Tests: wrapper swallows a thrown Error/Exception; onboarding still succeeds and RecoverBull still reaches WalletStarted when the recovery graph throws; the LN liveness read-only mode flags needsReactivation without re-registering; the heal drives Lightning Address with allowReregister:false; and a successful restore performs no Bullnym product writes.
UX-2 non-UI logic: the deterministic re-derivation that lets the dashboard self-heal a Get Paid product wallet that is missing locally while the product is ACTIVE on the server (master-doc contract #4 Q9/Q9b — the only permitted product-triggered wallet creation). - Expose prepareWallet() on PaymentPageFacade and PosFacade (the Lightning Address facade already exposes it), wiring each to its existing idempotent PreparePaymentPageWallet / PreparePosWallet usecase. No second derivation path: a present wallet returns created:false (a no-op that records nothing new, so no backup churn — the manifest insert de-dupes identical records), a missing wallet is re-derived from the fixed BIP85 path (101/102/103) and recorded in the manifest. - Add EnsureGetPaidProductWalletUsecase: given a product, calls the right prepareWallet() and maps the result to present / rederived / failed. Any failure is swallowed into `failed` so the dashboard can show a missing-wallet warning without breaking the rest of the hub. Consumed by the dashboard cubit in the UX-2 UI batch (#145).
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
2 participants
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.
Stack created with GitHub Stacks CLI • Give Feedback 💬