feat(jobs)!: deliver job results through object storage - #211
Conversation
BREAKING CHANGE: completed jobs now expose ResultHandle and completion requests require resultObjectKey; inline result ciphertext fields and MAX_INLINE_RESULT_BYTES are removed.
|
The latest updates on your projects. Learn more about Vercel for GitHub. 3 Skipped Deployments
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7c767d5bd5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ); | ||
| } | ||
| const actualHash = bytesToHex(sha256(bytes)); | ||
| if (actualHash.toLowerCase() !== handle.hash.toLowerCase()) { |
There was a problem hiding this comment.
When a completed Gateway response contains a truthy but malformed result object—for example, one with a missing or non-string hash—requireStatus accepts the external JSON without validating the new handle fields, and readRaw passes it here. This call then throws a raw TypeError from handle.hash.toLowerCase() rather than the documented JobRejectedError, preventing callers from reliably handling malformed or rolling-version Gateway responses. Validate every ResultHandle field at the response boundary before fetching or hashing it.
Useful? React with 👍 / 👎.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Replace the JSON/base64 result body with a length-prefixed JSON header followed by raw body bytes. BREAKING CHANGE: JobResult.body is now Uint8Array and existing sealed job-result plaintexts are no longer readable.
b1c154d to
36da1d8
Compare
## [0.19.0](v0.18.0...v0.19.0) (2026-09-10) ### Features * **cli:** the read loop - vana app read, escrow balance and fund, onchain ([a241c0a](a241c0a)), closes [vana-sdk#211](vana-com/vana-sdk#211) ### Reverts * **cli:** drop vana mcp --http ([2c9a79c](2c9a79c))
|
🎉 This PR is included in version 4.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
1 participant
Why
Enclave job results are capped at
MAX_INLINE_RESULT_BYTES(1 MiB) because the ciphertext rides inline in the job row. Vercel caps a function request or response body at 4.5 MB, so the inline path can never carry the 20-50 MB scopes we need. The pre-enclave direct read had no ceiling at all, so this cap is a regression, not a carried-over bound. It currently fails a real read: a ChatGPT-conversations scope returns jobstate: failed, surfaced to the user as an empty result.Decision and rationale:
personal-server-ts/docs/260904-result-delivery-plan.md.What
fix(jobs): surface real job failures from readRaw—readRawcalledopenResulton any terminal job without checkingstateorfailureReason, so a failed job surfaced as a generic "missing inline ciphertext" error. Independent of the change below and worth landing regardless.feat(jobs)!: use object storage for results— breaking protocol change:MAX_INLINE_RESULT_BYTESandresultCiphertextentirely.ResultHandle { objectKey, url, size, hash, expiresAt }.CompleteRequestbecomes{ fencingToken, resultHash, resultSize, resultObjectKey }.JobStatuscarries oneresult?: ResultHandle, present only when completed.openResultfetches the object publicly, verifies sha256 and size, then ECIES-decrypts raw bytes. No base64.readRaw's public signature is unchanged, so builders see nothing beyond the version bump.Notes
The removed fields shipped in 3.23.0 but nothing is in production, so removing them now is free and after the first builder depends on them it is a deprecation cycle.
Companion PRs: vana-storage #24, data-gateway #100, personal-server-ts #245, unity-surfaces #987, and lorebook #1.
🤖 Generated with Claude Code
https://claude.ai/code/session_017PxPMhmcBptiGgaJBoVyH1
Moksha release integration
The packaged chain-14800 anchors now trust the existing Moksha worker app/KMS identity, so production Web/Account builds can verify enclave identities without preview overrides. Mainnet anchors remain empty. The controller is excluded from the owner-key app allowlist.
Includes the existing SDK #186 withdrawal API to preserve Account dev compatibility when consumers replace their older SDK prerelease. This is a dependency integration; no withdrawal behavior was redesigned.
Published and registry-installed:
@opendatalabs/vana-sdk@3.23.0-pr.211.36da1d8(pr-211). Node and browser package entry points both verify a real Moksha public identity signature chain and retain the withdrawal API. All 1,376 tests pass (one skipped), full validation/build and autoreview pass, and GitHub Node20/22 plus key-scan checks are green. Fresh attestation admission remains a deployment responsibility; the saved signature-chain fixture does not claim fresh DCAP verification.