fix(orchestrator): name the model allow-list where enqueue_task picks it - #1194
Merged
Conversation
The `model` parameter on `enqueue_task` was declared as a bare optional string on both harness schemas, while `checkEnqueueGuards` rejects anything outside `VALID_MODELS`. The allow-list only appeared in the rejection message, so an agent had to guess a gateway model id, trip the `invalid-model` guard, and spend a turn reading the list back. Move the list into a shared `ENQUEUE_MODEL_DESCRIPTION` and describe the field with it on both the zod schema and the pi typebox mirror, so the guard and the description cannot disagree. Generated-By: PostHog Desktop Task-Id: 93b396ed-9a30-4d56-bd97-6bd31c232436
🧙 Wizard CIRun the Wizard CI and test your changes against wizard-workbench example apps by replying with a GitHub comment using one of the following commands: Test all apps:
Test all apps in a directory:
Test an individual app:
Show more apps
Test against a Context Mill branch:
Add Results will be posted here when complete. |
edwinyjlim
approved these changes
Sep 3, 2026
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
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.
Problem
enqueue_taskaccepts an optionalmodeloverride. The guard behind it(
checkEnqueueGuards) rejects any value outside the wizard'sVALID_MODELSallow-list — but the field was declared as a bare optional string on both
harness schemas, with no description. The allow-list existed only inside the
rejection message.
So an agent that wanted to pin a task's model had to guess a gateway model id,
trip the
invalid-modelguard, read the list back out of the error, andre-issue the enqueue. Telemetry shows this happening across separate runs of
the seeded warehouse-source flow: every occurrence is one wasted turn on a
question the schema could have answered up front.
Why
Raised while reading orchestrator telemetry for the data-source connection
task:
orchestrator guard tripped/invalid-modelwas one of the fewstructured failure signals in the window, and it is entirely self-inflicted —
the agent is asked to supply a value from a list it is never shown.
Changes
ENQUEUE_MODEL_DESCRIPTIONtoqueue-tools.ts, built fromVALID_MODELS, so the guard and the description share one source.modelfield with it on bothenqueue_taskschemas: the zodshape used by the
wizard-toolsMCP server and the typebox mirror thepiharness mounts. The orchestrator runs on
pi, so a description present onlyon the MCP schema would not be in effect.
default — the task's own model is already resolved by the switchboard.
No behaviour change to the guard itself; a rejected model is still rejected.
Test plan
pnpm build && pnpm fixclean. New tests inorchestrator/__tests__/queue-tools.test.ts:isValidModelaccepts, so theadvertised list and the guard cannot drift apart
enqueue_taskschema'smodelfield actually carries itExisting orchestrator suite (156 tests) passes.
Created with PostHog Desktop