feat(web-client): expose stable errorCode on thrown JS errors for variant dispatch#25
Open
WiktorStarczewski wants to merge 9 commits intomainfrom
Open
feat(web-client): expose stable errorCode on thrown JS errors for variant dispatch#25WiktorStarczewski wants to merge 9 commits intomainfrom
WiktorStarczewski wants to merge 9 commits intomainfrom
Conversation
4 tasks
WiktorStarczewski
force-pushed
the
wiktor/migrate-2060-errorcode
branch
from
ea631d2 to
475991d
Compare
…iant dispatch Migrated from 0xMiden/miden-client#2060 (author: WiktorStarczewski) as part of the web-sdk split. Original PR: 0xMiden/miden-client#2060 Depends on the ApplyTransactionAfterSubmitFailed error variant added by miden-client #2059 — landing this requires the upstream miden-client dep on web-sdk's main to include that change first.
WiktorStarczewski
force-pushed
the
wiktor/migrate-2060-errorcode
branch
from
475991d to
0235262
Compare
…mit-failed) This web-sdk PR was migrated from miden-client#2060, but the Rust ApplyTransactionAfterSubmitFailed ClientError variant it dispatches on lives on miden-client#2059 (which #2060 stacks on). Repointing the workspace dep at #2059's branch so CI can compile. Revert before merge — see PR description for the merge sequence.
WiktorStarczewski
added
the
no changelog
WiktorStarczewski
added a commit
that referenced
this pull request
Apr 30, 2026
Now that miden-client#1835's wiktor-storekeys branch has been merged with miden-client@dab6cf7b (the same snapshot of next that web-sdk currently pins), the dep retarget that #23/#25/#26/#31 use works for this PR too. Local 'cargo check --workspace --target wasm32-unknown-unknown' is clean (was 23 errors before the upstream merge, due to the alpha-protocol mismatch the PR description mentions). Revert before merge — see PR description merge gate.
This was referenced Apr 30, 2026
…dep retarget Brings in the auto-patch infrastructure landed in #65 (composite action, mergeability gate, lefthook guard, dev script, docs). Drops the manual [patch]-style retarget block we'd added to Cargo.toml: with the linked 'Client PR: #2059' marker in this PR's description, the CI workflow auto-injects an equivalent in-place rewrite at run time. This commit is the verification that the auto-patch system works end-to-end on a real migration PR. Expectations: - Cargo.toml diff vs main is now empty (no manual retarget). - The Inject linked miden-client PR step reads 'Client PR: #2059' from this PR's body, resolves miden-client#2059's head, rewrites the dep in place on the runner, and posts a sticky comment summarizing the patch (single comment per run, deduped via the linked-client-pr sticky header). - Build/Test runs against miden-client@wiktor/apply-tx-after-submit-failed just like before — but the retarget is implicit, not committed.
|
🔗 Linked client PR:
This run is testing against the linked PR's head. The published artifact will use the canonical Local-dev parity: |
WiktorStarczewski
added a commit
that referenced
this pull request
Apr 30, 2026
PR #25's verification run surfaced a coverage gap: my initial wiring in #65 only patched build.yml's build-wasm and test.yml's build-web-client-dist-folder + verify-release-build. But Clippy WASM (in lint.yml) and publint + attw (in check-publish.yml) ALSO compile cargo against the workspace's miden-client dep — without the patch, they hit canonical crates.io `miden-client = "0.14.5"` and fail with `error[E0599]: no variant named `ApplyTransactionAfterSubmitFailed`` when the PR depends on an unreleased upstream variant. Add the action call after checkout in both jobs. Both run with comment=false (the default); build-wasm remains the single sticky- comment poster.
WiktorStarczewski
added a commit
that referenced
this pull request
Apr 30, 2026
PR #25's verification run surfaced a coverage gap: my initial wiring in #65 only patched build.yml's build-wasm and test.yml's build-web-client-dist-folder + verify-release-build. But Clippy WASM (in lint.yml) and publint + attw (in check-publish.yml) ALSO compile cargo against the workspace's miden-client dep — without the patch, they hit canonical crates.io `miden-client = "0.14.5"` and fail with `error[E0599]: no variant named `ApplyTransactionAfterSubmitFailed`` when the PR depends on an unreleased upstream variant. Add the action call after checkout in both jobs. Both run with comment=false (the default); build-wasm remains the single sticky- comment poster.
WiktorStarczewski
added a commit
that referenced
this pull request
Apr 30, 2026
…#73) Two issues from PR #25's verification run: 1. The 'linked-client-pr-ready' custom commit status the gate posts never landed. Cause: the workflow's permissions block has 'checks: write' (for check-runs) but not 'statuses: write' (which the POST /repos/.../statuses/$sha endpoint requires). The gh api POST 403'd silently — and #2 below ate the error. 2. set_status() redirected gh's stdout to /dev/null. With no error visible, the silent 403 looked like 'job ran successfully' even though the readiness verdict never reached the commit. This commit: - adds 'statuses: write' to the workflow permissions - drops the >/dev/null redirect so any future API failure is loud
WiktorStarczewski
added a commit
that referenced
this pull request
Apr 30, 2026
…#74) Two issues from PR #25's verification run: 1. The 'linked-client-pr-ready' custom commit status the gate posts never landed. Cause: the workflow's permissions block has 'checks: write' (for check-runs) but not 'statuses: write' (which the POST /repos/.../statuses/$sha endpoint requires). The gh api POST 403'd silently — and #2 below ate the error. 2. set_status() redirected gh's stdout to /dev/null. With no error visible, the silent 403 looked like 'job ran successfully' even though the readiness verdict never reached the commit. This commit: - adds 'statuses: write' to the workflow permissions - drops the >/dev/null redirect so any future API failure is loud
WiktorStarczewski
added a commit
that referenced
this pull request
Apr 30, 2026
#75) Previous form: read -r body base_ref state <<<"$(gh api ... --jq '"\(.body // "")\t\(.base.ref)\t\(.state)"')" PR bodies are multi-line and the marker is itself space-separated. read defaults to whitespace IFS and only consumes through the first newline, so a body starting with 'Client PR: #2059\n...' assigned: body = 'Client' base_ref = 'PR:' state = '#2059' The gate then hit the early-return: if [ "$state" != "open" ] && [ "$state" != "OPEN" ]; then echo "PR #$PR_NUM is $state — skipping." exit 0 fi …and exited with the visible-in-the-job 'PR #25 is #2059 — skipping.', never posting the linked-client-pr-ready custom status. The job logged 'success' because exit 0 is what the early-return does, but the readiness verdict never reached the commit. Fix: - body = separate gh api call (multi-line tolerated naturally) - base_ref + state packed into a tab-separated single-line, read with IFS=$'\t' so a hypothetical future whitespace in either field wouldn't repeat the bug - Same IFS=$'\t' added to the second read of (merged, merge_commit_sha) for consistency, even though neither field can contain whitespace today
WiktorStarczewski
added a commit
that referenced
this pull request
Apr 30, 2026
#76) Previous form: read -r body base_ref state <<<"$(gh api ... --jq '"\(.body // "")\t\(.base.ref)\t\(.state)"')" PR bodies are multi-line and the marker is itself space-separated. read defaults to whitespace IFS and only consumes through the first newline, so a body starting with 'Client PR: #2059\n...' assigned: body = 'Client' base_ref = 'PR:' state = '#2059' The gate then hit the early-return: if [ "$state" != "open" ] && [ "$state" != "OPEN" ]; then echo "PR #$PR_NUM is $state — skipping." exit 0 fi …and exited with the visible-in-the-job 'PR #25 is #2059 — skipping.', never posting the linked-client-pr-ready custom status. The job logged 'success' because exit 0 is what the early-return does, but the readiness verdict never reached the commit. Fix: - body = separate gh api call (multi-line tolerated naturally) - base_ref + state packed into a tab-separated single-line, read with IFS=$'\t' so a hypothetical future whitespace in either field wouldn't repeat the bug - Same IFS=$'\t' added to the second read of (merged, merge_commit_sha) for consistency, even though neither field can contain whitespace today
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.
Client PR: 0xMiden/miden-client#2059
Migrated from miden-client#2060 as part of the web-sdk split (web/WASM components moved out of miden-client into this dedicated repo — see miden-client 0xMiden/miden-client#1992 / 0xMiden/miden-client#2135).
Closes miden-client#2066.
Summary (per the original PR)
errorCodestring property to JS errors thrown by the WebClient.err.errorCode === 'ApplyTransactionAfterSubmitFailed'instead of parsing error message strings.Currently exposed codes:
ApplyTransactionAfterSubmitFailed— tx on chain, apply failed locallyAccountLocked— account state out of syncNoteNotFoundOnChain— note not committed yetRpcError— network/node issueThe CHANGELOG and other miden-client-side changes from the original PR stay on miden-client#2060. Note: the marker points at miden-client 0xMiden/miden-client#2059 (not 0xMiden/miden-client#2060) because the
ApplyTransactionAfterSubmitFailedClientErrorvariant lives on 0xMiden/miden-client#2059 — 0xMiden/miden-client#2060 stacks on top of it.