Skip to content

v0.62.1: Clearer Waiting Messages

Choose a tag to compare

@github-actions github-actions released this 21 Oct 06:29
· 208 commits to main since this release
bf5176b

Changed

  • Two first-run messages say more. GET /readyz and GET /plugboard/ready now explain the 503 you get after an OpenCode restart: "waiting for OpenCode to load plugboard", that the first model request to an app or a warm-up call makes it ready, and a link to the warm-up page. Readiness itself is unchanged: /readyz stays 503 until an app directory has served a request, because answering 200 earlier would send traffic to a server whose first request still has to boot the directory. An unknown model on a Gemini generateContent, streamGenerateContent or countTokens call now points at GET /v1beta/models, not GET /v1/models.

The full story

1 commit since v0.62.0, grouped by type and oldest first. Each entry is the commit message as written.

Fixes (1)

fix(http): say why /readyz is 503 after a restart, and point Gemini at /v1beta/models (0c21cdf)

Two bits of first-run friction left over from the last walkthrough.

/readyz: after an OpenCode restart it answered 503 "no app directory has been used since start; one model request to an app confirms it". The reason now starts with "waiting for OpenCode to load plugboard", says the first model request to an app or a warm-up call makes it ready, and links the warm-up page. The old phrase is still inside the text.

Gemini: an unknown model on generateContent, streamGenerateContent and countTokens said "GET /v1/models lists the models you can call", a route a Gemini client does not use. encodeGeminiError now rewrites that hint to GET /v1beta/models for model_not_found, so every path that reaches a Gemini error body (route, session, fallback) gets it. The GET /v1beta/models/{model} route already did.

Decision: readiness rule unchanged. servingConfirmed is the only signal that an app directory has booted in this process; answering 200 on listener-up alone would send load-balancer traffic to a server whose first request still boots the directory (a few seconds, and the pump and catalog load there too). Wording only.

Rejected: threading a list-route parameter through resolveModel, checkAppModel and the session caller. The encoder is the one place every Gemini error passes through.

Docs: errors.md (not_ready), configuration.md (errors table, /readyz line), warm-up.md. CHANGELOG [Unreleased] Changed. Scripted transcripts of the four Gemini examples regenerated; each diff is only the message line (and its fieldViolations copy). Tests: newcomer-errors (generate, stream and count on a Gemini route), readyz (exact reason).

Validation: bun run validate --skip examples passes. The full examples step passed through every client up to langchain4j, which needs a Java runtime this machine lacks (unchanged OpenAI-shape transcripts).


Full diff: v0.62.0...v0.62.1