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
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