Add 200/PROCESSING to the wallet export endpoint - #854
Conversation
POST /internal-accounts/{internalAccountId}/export (exportInternalAccount,
EXPORT_WALLET) is the last signed-retry endpoint left off the 200/PROCESSING
contract (SP-3579). Its wallet-provider activity is only optimistically
synchronous like the rest, but the spec documented a single terminal 200 — so
an approval- or consensus-gated export had no documented shape at all, and the
undocumented one it used to answer (202 + operationId) was a dead end: no fetch
endpoint exists, the encrypted credentials are deliberately never stored, and
the challenge had already been consumed, so every re-send was a 401.
The 200 widens to a new InternalAccountExportResult wrapper — anyOf:
[InternalAccountExportResponse, WalletOperationProcessing] — the competing-200
case, same shape and same anyOf-over-oneOf reasoning as the verify endpoint
(neither member shares a discriminator field with WalletOperationProcessing's
`status`, and this repo's spectral rules require a discriminator on every
oneOf). The existing 202 (SignedRequestChallenge) is untouched: that is the
sign-and-resubmit leg, a different state.
Export differs from the other six endpoints in one integrator-visible way, so
the prose says it: because the credentials are never stored server-side,
re-sending the signed retry is the only way to receive them. Grid's own
reconciliation settles the operation but has nothing to hand back, so the
"stop retrying and check back later" advice that holds for the others does not
hold here — the completion webhook tells the client when a re-send will
succeed. The challenge is consumed only by the attempt that actually returns
credentials, so a PROCESSING response leaves it usable and a delivered export
still refuses a second one.
Docs: export joins the still-processing endpoint table and the shares-its-200
callout in authentication.mdx, and the export walkthrough gets the branch in
its sequence diagram plus the pointer every other flow already has. The
bundled openapi.yaml moves WalletOperationProcessing earlier in components —
generator ordering follows first reference, and export now references it
before the auth paths do.
Sequencing: companion to the webdev export PR that makes the endpoint behave
this way (branch grid-turnkey-export-processing). Behind
Knob.GRID_TURNKEY_ASYNC_EXPORT, default off.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
✱ Stainless preview builds for gridThis PR will update the cli go kotlin openapi php python ruby typescript Edit this comment to update them. They will appear in their respective SDK's changelogs. ✅ grid-typescript studio · code · diff
✅ grid-openapi studio · code · diff
✅ grid-ruby studio · code · diff
✅ grid-go studio · code · diff
✅ grid-kotlin studio · code · diff
✅ grid-python studio · code · diff
✅ grid-php studio · code · diff
✅ grid-cli studio · code · diff
This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push. |
Greptile SummaryThe PR expands wallet export’s successful response contract to include a
Confidence Score: 4/5The response-schema change appears sound, but the undefined The new API union and generated bundles are internally consistent, while the public retry instructions currently direct clients to a webhook type that the API does not define. Files Needing Attention: openapi/paths/internal_accounts/internal_accounts_{id}_export.yaml; mintlify/snippets/global-accounts/exporting-wallet.mdx
|
| Filename | Overview |
|---|---|
| openapi/components/schemas/internal_accounts/InternalAccountExportResult.yaml | Adds an anyOf wrapper matching existing competing-200 response patterns. |
| openapi/paths/internal_accounts/internal_accounts_{id}_export.yaml | Documents and exposes the PROCESSING response correctly, but recommends an undefined completion event. |
| mintlify/snippets/global-accounts/authentication.mdx | Adds export to the common PROCESSING guidance and explains its challenge-expiry exception. |
| mintlify/snippets/global-accounts/exporting-wallet.mdx | Adds the PROCESSING retry loop but repeats the undefined webhook subscription advice. |
| openapi.yaml | Generated bundle faithfully reflects the modular schema and path changes. |
| mintlify/openapi.yaml | Generated Mintlify bundle remains synchronized with the root OpenAPI bundle. |
Sequence Diagram
sequenceDiagram
participant Client
participant Grid
Client->>Grid: Initial export request
Grid-->>Client: 202 challenge
Client->>Grid: Signed retry
alt Wallet activity still settling
Grid-->>Client: 200 PROCESSING
Client->>Grid: Repeat identical signed retry
else Activity settled
Grid-->>Client: 200 encryptedWalletCredentials
end
Reviews (1): Last reviewed commit: "feat: add 200/PROCESSING to the wallet e..." | Re-trigger Greptile
2 participants
POST /internal-accounts/{internalAccountId}/exportis the last signed-retry endpoint left off the 200/PROCESSING contract, and the gap was not cosmetic: its wallet-provider activity is only optimistically synchronous like the rest, but the spec documented a single terminal200, so an approval- or consensus-gated export had no documented shape — and the undocumented one it answered (202+operationId) was a dead end, since no fetch endpoint exists, the encrypted credentials are deliberately never stored, and the challenge had already been consumed, making every re-send a401. This widens the200to a newInternalAccountExportResultwrapper (anyOf:InternalAccountExportResponse|WalletOperationProcessing) — the competing-200 case, following the verify endpoint's named-wrapper pattern from #850, with the existing202challenge leg untouched. The prose calls out the one way export differs from the other six endpoints: because the credentials are never stored, re-sending the signed retry is the only way to receive them, so the "stop retrying and check back later" advice that holds elsewhere does not hold here, and the challenge is consumed only by the attempt that actually returns credentials.Sequencing: companion to the webdev PR that makes the endpoint behave this way (branch
grid-turnkey-export-processing, stacked on the session-refresh reconcile-finalize branch). Both sides are behindKnob.GRID_TURNKEY_ASYNC_EXPORT, default off, so this documents the contract the knob-on path will honor. Stacked on #853 (sp3579-wallet-operation-processing) — review that first.make buildandmake lintare green (0 errors; the 148 warnings / 515 infos are the repo-wide pre-existing baseline, unchanged by this diff).🤖 Generated with Claude Code