Update e2e/lifecycle harnesses + setup for URL-scoped bundles - #101
Merged
Conversation
Bundles are now submitted to /providers/:ppPublicKey/bundles instead of the channel-only route. The client config requires E2E_PP_PUBLIC_KEY and submitBundle / waitForBundle / send all encode the PP in the URL. send also returns the bundle id and accepts waitForCompletion: false so callers can detect or expire a bundle before it settles.
Replaces the single-council / single-PP setup with a 3-council fleet (Mercosur, Europe, North America) and 12 country-bound PPs (one per region's countries). The Council Admin owns all 3 councils; one operator authenticates once, derives 12 PP keypairs from HKDF(masterSeed, "pp" || index), and registers each PP on its council via /dashboard/pp/register + admin approve + add_provider. State file records COUNCIL_COUNT, PP_COUNT, per-PP jurisdiction and councilIndex, plus OPERATOR_PK/SK so send-loop and demo scripts can authenticate as the operator without re-deriving.
One invocation walks every country in the fleet, running a full cycle per country: deposit → COUNT sends → one FAILED bundle → one EXPIRED bundle → withdraw. Sender / receiver names are sampled from a per- country pool (Mariana BR, Carmen AR, Sophie DE, ...) so dashboards see entity variety instead of two stock names. Each pair is registered via POST /api/v1/entities before submitting any bundles. - FAIL injection: deposit 0.5 XLM, then submit a SPEND for that UTXO with a CREATE for 2× the amount. Server admits, executor sim rejects on the unbalanced operation, bundle settles as FAILED. - EXPIRE injection: submit a bundle without waiting, then call /api/v1/dashboard/bundles/expire with the bundle id; settles as EXPIRED. - Demo wrapper (network-dashboard-demo.ts) shells out to send-loop.sh per country. Opt out per cycle with FAIL=false / EXPIRE=false. Removes the older TARGET_COUNTRY env (the loop now always covers the whole fleet).
Bundles are now URL-scoped to /providers/:pp/bundles and require the submitter to be an APPROVED entity. The two existing harnesses needed two small updates to keep passing CI against the new provider-platform: - e2e/setup.sh writes E2E_PP_PUBLIC_KEY=$PROVIDER_PK to contracts.env so lib/client/config.ts can resolve a PP for every submission. - e2e/main.ts registers Alice and Bob via POST /api/v1/entities right after authenticate, before the deposit / send flow. - lifecycle/main.ts sets ppPublicKey on the built Config and registers Alice and Bob the same way before deposit and send.
5 tasks
AquiGorka
added a commit
that referenced
this pull request
May 29, 2026
…nstant (#103) ## Summary Follow-up to #101 — fixes the harnesses that were missed because they live next to (but aren't) the runners that the first PR touched: - **`lifecycle/ci-test.ts`** is what the lifecycle Docker compose actually invokes (`lifecycle/main.ts` is local-only). Now wires `ppPublicKey` on Config and registers Alice/Bob via /api/v1/entities before deposit/send. This is what unblocks **provider-platform's** lifecycle CI. - **`e2e/governance/uc2-approve-reject.ts`** still read `.councilMembership` (singular) on the dashboard /pp/list response; provider-platform PR #103 had renamed it to `.councilMemberships` (plural array) months ago. Updated reads to `[0]?.status` / `.length === 0`. - **`e2e/pos-instant/main.ts`** registers `keys.payService` as APPROVED before the instant payment flow, since pay-platform authenticates to provider-platform under that key and otherwise trips the SUBMITTER_NOT_APPROVED gate. - **`test/setup-e2e.ts`** writes `E2E_PP_PUBLIC_KEY` to /config/contracts.env. (`e2e/setup.sh` already had this in the CI flow; the local `./test.sh e2e` flow uses the test/ setup script and needs the same line.) ## Test plan Locally (`./test.sh all`), all 5 suites green: e2e, otel, governance, lifecycle, pos-instant. After this merges, re-running provider-platform's PR CI (Moonlight-Protocol/provider-platform#106) should flip lifecycle from red to green.
AquiGorka
added a commit
to Moonlight-Protocol/provider-platform
that referenced
this pull request
May 29, 2026
) ## Summary Three bundled changes for the provider-dashboard work: 1. **`feat(entities)`** — rename `users` → `entities`, add POST /api/v1/entities for KYC/KYB-style approval, gate bundle submission on the submitter's entity being APPROVED (`SUBMITTER_NOT_APPROVED`). 2. **`feat(bundles)`** — bundles submitted to `/api/v1/providers/:ppPublicKey/bundles` instead of channel-only. Each bundle row carries `pp_public_key`. channel-resolver requires explicit PP, returns the PP-bound signer/channel client. `bundle.jurisdiction_from/to` dropped (now derived from the submitter's entity). dashboard `listRecentBundles` is PP-scoped and returns entityName / jurisdictions / aggregated amount. Event emission moves from `emitForChannel` (every PP on the channel) to `emitForBundles` / `emitForPp` so dashboards only see events for bundles that belong to them. 3. **Version bump** to 0.7.0 (minor — new surface area). Migrations: 0014 (rename users→entities), 0015 (drop bundle jurisdictions), 0016 (bundle pp_public_key). ## CI note Cross-repo deadlock with `local-dev` and `pay-platform`: - This PR's e2e + lifecycle CI uses `local-dev@main` which still calls the old `/api/v1/bundle` route — will be red until local-dev's PR (Moonlight-Protocol/local-dev#101) merges. - Pay-platform PR (Moonlight-Protocol/pay-platform#35) also needs to merge to fix the same old-URL call from production payment flow. Locally, with all three branches checked out, `./test.sh all` is green across e2e + otel + governance + lifecycle + pos-instant. ## Test plan - [x] deno fmt --check (288 files) - [x] deno lint (248 files) - [x] deno task test:unit (64 passed) - [x] deno task test:pay (136 passed) - [x] Local `./test.sh all` against local-dev + pay-platform branches — all 5 suites green
2 tasks
AquiGorka
added a commit
that referenced
this pull request
Jun 2, 2026
…tack (#109) ## Summary Restores recording-rig spec 03 (Bob + Alice private transfer) end-to-end after the stack-wide moves landed since 2026-05-22. Specs 01, 02, 04 were already green on this branch's stack and are untouched. Just the rig changes — no application code in local-dev. **Depends on `browser-wallet#20` and `provider-platform#109` being deployed first.** ## What broke + how this fixes it Pulled from the pairing thread's diagnose: | Layer | Symptom | Fix lives in | |---|---|---| | Channel-create against local stack | `Failed to fetch Quorum Contract ID` (SIM_002) — wallet's service-worker `fetch` to `http://localhost:8000/soroban/rpc` blocked by extension_pages CSP added in browser-wallet#18 | browser-wallet#19 (already merged) | | Bundle submission | 404 `/api/v1/bundle` — provider-platform#106 moved bundle endpoints under `/api/v1/providers/:ppPublicKey/entity/bundles` | browser-wallet#20 | | Bundle submission | 403 `Submitter not approved` (BND_011) — wallet had no surface for KYC submission | browser-wallet#20 + provider-platform#109 (entityStatus on SEP-10 verify) | | Spec 03 itself | `env.PP_PK` is the operator pubkey, not the PP's own pubkey that goes in the URL path | **this PR** | | Spec 03 itself | Wallet form needs the PP pubkey; KYC prompt lives inside the channel-picker sheet, which closes after Approve | **this PR** | ## Spec / fixture changes - `specs/03-private-transfer.spec.ts`: discover the PP's pubkey from council-platform's `/api/v1/public/providers?councilId=…` (label match on `getProviderName()`), and feed it + a per-wallet KYC entity name into `addAndConnectProvider`. - `fixtures/browser-wallet.ts` (`addAndConnectProvider`): - Fill the new `#provider-pubkey` input added in browser-wallet#20. - After sign-Approve, re-open the channel-picker sheet (the popup goes back to home with the sheet closed). - If the wallet renders the "Submit KYC" prompt (entityStatus != APPROVED), click it, fill name + password, submit. - Press Escape to close the sheet so the home Receive/Send/Ramp buttons aren't covered by the overlay. No other beats changed. The original `showReceive` / `deposit` / `send` / `withdraw` / `toggleToPublicView` flow is untouched. ## Verification Local stack: 3 councils × 12 PPs (post-#101 setup) + spec-02's Provider Helios, on `provider-platform@feat/sep10-verify-returns-entity-status` (0.7.0) + `browser-wallet@feat/per-pp-urls-and-kyc-step`. - `01-council-onboard`: PASS (2.4 min) - `02-provider-create-join-approve`: PASS (3.2 min) - `03-private-transfer`: PASS (5.4 min) — full Bob→Alice flow, withdraw, closing public-balance beat - `04-dashboard-tour`: PASS (24 s) ## Out of scope (follow-up) - A second-look refactor of the wallet's UX so KYC is also surfaced at the home level (not only inside the sheet) — current placement matches where the provider row lives, but a top-level banner would prevent the recording-rig sheet dance. - Public PP-discovery endpoint on provider-platform so the wallet doesn't need the operator to paste the PP pubkey manually. ## Test plan - [x] All 4 specs green individually on the matched stack - [ ] Full-suite `RUN_ID=… npm run record` end-to-end after browser-wallet#20 + provider-platform#109 merge
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.
Summary
Updates local-dev to match the upcoming provider-platform changes:
CI note
Provider-platform main does not yet have the URL-scoped routes or /entities endpoint that the updated client targets, so this PR's e2e + lifecycle CI will be red until the matching provider-platform PR lands (https://github.com/Moonlight-Protocol/provider-platform branch feat-provider-dashboard-rework). Per the iterate-provider-dashboard work this is the deliberate unblock order — landing this first lets provider-platform's CI use the new client on its own e2e run.
Test plan