fix: respect retryCount in json_schema structured output - #25534

Issue for this PR

Closes #25430

Type of change

• Bug fix

What does this PR do?

format.json_schema.retryCount was defined in the API schema (message-v2.ts) but never read in prompt.ts. When the model failed to produce structured output, the code always set retries: 0 in the StructuredOutputError regardless of what the caller passed, and never actually retried.

There was also a second bug: because OutputFormatJsonSchema was defined as a Schema.Class, the HTTP response serialization (encode direction) would crash with a SchemaError whenever retryCount was present in the stored message. This caused GET /session/:id/message to return 400 for any session that used json_schema format with an explicit retryCount.

Changes:

1. packages/opencode/src/session/message-v2.ts — converted OutputFormatText and OutputFormatJsonSchema from Schema.Class to Schema.Struct (consistent with the rest of the file). Schema.Class requires a class instance for encoding; Schema.Struct handles plain objects correctly, which is what the DB returns.

2. packages/opencode/src/session/prompt.ts — added a retryAttempt counter alongside the existing step counter. When the model finishes without producing structured output, the code now checks format.retryCount (defaulting to 2) and retries up to that many times before setting the error. The retries field in StructuredOutputError now reflects the actual number of attempts made.

How did you verify your code works?

Ran the server locally (bun dev serve) and tested via Postman:

1. POST /session — created a new session
2. POST /session/:id/prompt_async with format.retryCount: 1 and a prompt designed to avoid structured output
3. GET /session/:id/message — previously returned 400 due to the schema bug; now returns 200

Also ran bun typecheck — no errors.

Screenshots / recordings

Screenshot 1 — POST /session returning 200 with the new session ID:

Screenshot 2 — POST /session/:id/prompt_async request body showing retryCount: 1:

Screenshot 3 — Server logs showing GET /message returning 200 (previously 400):

• I have tested my changes locally
• I have not included unrelated changes in this PR