fix(ci): bump opencode Azure apiVersion to support /responses endpoint (#22)#24
Merged
Conversation
#22) The CUA smoke probe was returning MODEL_CAPABLE=false because opencode's @ai-sdk/azure provider got 'API version not supported' from Azure on /openai/v1/responses with apiVersion=2024-08-01-preview. Split into two envs: keep the CUA driver on 2024-08-01-preview (chat-completions only) and bump the opencode-side provider config to 2025-04-01-preview, which supports the new responses API. Effect: send_message/multi_turn scenarios get included again in CUA smoke when the probe succeeds.
Step 11 'Start opencode server' has hung past the 45-min job timeout in two consecutive runs (27195348071, 27198238465). Local boot of opencode-ai 1.16.2 with the same heredoc config is healthy in 3s, so something is wrong specifically on the GH-hosted runner — likely curl post-loop waiting indefinitely on an unresponsive server. Adds: - set -x for command tracing - --connect-timeout 2 -m 5 on every curl so hangs cannot exceed 5s - HEALTHY flag + explicit exit 1 (drops the unbounded post-loop curl) - Periodic dump every 10s: server log tail, ss listening sockets, process liveness — so we can see WHY the server isn't replying Pure diagnostics; no behaviour change for the green path.
Reproduced the probe failure locally against the same Azure resource:
all date-based api-versions (2024-08-01-preview, 2024-12-01-preview,
2025-01-01-preview, 2025-03-01-preview, 2025-04-01-preview) return:
{"error":{"code":"BadRequest","message":"API version not supported"}}
Only api-version=preview and api-version=v1 succeed (200). This is the
new Azure OpenAI v1 responses-API style; date strings are reserved for
the legacy /openai/deployments/{model}/chat/completions endpoint.
@ai-sdk/azure 3.x already defaults apiVersion to "preview" (per the
type definition: "Custom api version to use. Defaults to `preview`."),
so this aligns the workflow with the SDK default. Probe should now
return MODEL_CAPABLE=true and the send_message scenario will run.
Owner
Author
|
Reproduced root cause locally — it was not the api-version date being too old. The Azure resource's Only Pushed |
Assistant bubbles can take 15+ seconds to appear after send. Previous 5-second wait was too short and caused false failures even when API calls succeeded. Re-check screenshots periodically up to 30s total.
The send action's auto-locate filtered for y1 > 2200 and fell back to hardcoded (996, 2358) — both assume a 1080x2400 panel. The CI emulator (API 30 google_apis pixel profile) is 1080x1920, so: - the bottom_buttons filter never matched any clickable element - the fallback tap landed off-screen → 'ping' message never sent, scenario timed out with no bubbles. Switch to a screen-relative threshold (bottom 25%) and a fallback that uses get_screen_size() to land in the bottom-right corner regardless of device resolution. This was masked until now because send_message was gated by MODEL_CAPABLE=false in earlier CI runs. Refs: #22
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.
Why
cua-smokeprobe returnsMODEL_CAPABLE=false(run 27148871066) because opencode's@ai-sdk/azureprovider was hitting/openai/v1/responseswith the oldapiVersion=2024-08-01-previewand getting back:{"error":{"code":"BadRequest","message":"API version not supported"}}That collapsed the smoke to
connect_and_verify_sessions,verify_session_listand skippedsend_message/multi_turn— the actual reply path the issue asked us to cover.What
Split into two envs:
AZURE_OPENAI_API_VERSION=2024-08-01-preview— keeps the CUA driver pinned (chat-completions endpoint, proven working).OPENCODE_AZURE_API_VERSION=2025-04-01-preview— used inopencode.jsonprovider config, supports the new/responsesAPI.Verification
On merge, the CUA smoke probe should return HTTP 200 with an assistant
pongreply →MODEL_CAPABLE=true→ scenarios becomeconnect_and_verify_sessions,send_message,verify_session_list. Watch theProbe opencode model capabilitystep in the next run.Closes #22.