Repository navigation
fix: keep extension fields on CreateTaskResult and GetTaskResult - #32
Open
jayzuccarelli wants to merge 1 commit into
Open
jayzuccarelli wants to merge 1 commit into
jayzuccarelli wants to merge 1 commit into
Conversation
Both results extend the open Result type, but their v2 schemas were plain z.object wrappers, so unknown top-level keys were stripped on the polling path. The notification params schema already uses openObject for the same reason. Use it for both results as well, so projectTask() sees the same extension fields whether a task arrives by tasks/get or notifications/tasks. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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. |
This branch has not been deployed
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
CreateTaskResultandGetTaskResultboth extend the openResulttype, but their v2 runtime schemas wrap the shape in a plainz.object, which strips unknown top-level keys. The notification params schema in the same file already usesopenObjectfor exactly this reason (see the comment aboveTaskStatusNotificationParamsV2Schema).The effect is that the same task carries different data depending on how it reaches the client. With a
"vendor/trace"field on the task:TaskView.extensionsnotifications/tasks{ "vendor/trace": { hop: 1 } }tasks/get{}CreateTaskResult{}This PR uses
openObjectfor both result schemas, so all three paths keep the field.Changes
packages/ext-tasks/src/core/v2/schemas.ts:CreateTaskResultV2Schemaand the wrapper side ofGetTaskResultV2SchemauseopenObjectinstead ofz.object.packages/ext-tasks/src/core/v2/index.test.ts: new case next to the existing notification one, asserting that an extension field survives decoding for both results. It fails onmainand passes here.Testing
npm run checkinpackages/ext-tasks(provenance, prettier, eslint, typecheck, 193 tests, build, exports): passes.npm run check:schema:tsand the generated-schema check at the repo root: pass.I did not open an issue or raise this in the Agents WG first, since it is a small fix that follows a pattern already in the file. Happy to move it there if you prefer.
AI assistance (Claude Code) was used to find the gap, write the change and run the checks. I reviewed the diff.