Skip to content

Release canary reports qualified for recovered ACP traffic after a native key-expired error #234

Closed

Description

@sumitake

A fresh staged 7.0.9 / runtime 5.0.10 release matrix reported qualified=true even though its OpenCode Go case did not return a substantive model answer. Caller inspection correctly held qualification incomplete; nothing was published or installed.

Observed case: architecture.repository, explicit target zhipu, standard quality / maximum effort, one attempt, no replay. The selected carrier was opencode/plan.repository; native configuration selected an opencode-go/ model. The correlated terminal ACP response was JSON-RPC error -32603, service session, error name APIError, reporting an expired API key and saying that signing in again would not renew it. There were zero agent message/thought chunks. No credential value, local path, private prompt, or native account identifier is included here.

The runtime preserved bounded catalog/control/error traffic as recovered content. Process observations reported return code zero, provider status OK and confirmed cleanup. Fixture HEAD was unchanged. These facts are separate from successful model execution. The original returned frames and failed case remain preserved; no key search, replacement, renewal, alternate provider, or replay was attempted.

The matrix currently checks mechanical transport/content-preservation/source predicates. Its qualified label can therefore be mistaken for fixture acceptance when recovered bytes contain only native protocol/error traffic. Fourteen other cases had substantive fixture answers; the full matrix must not be repeated to fill this isolated gap.

Please clarify the report's mechanical scope and the separate caller fixture-acceptance obligation. An optional bounded correlated ACP-error observation may improve diagnostics, but must not discard raw content, turn provider formatting into a content gate, infer provider-wide health, silently switch credentials/billing, or authorize replay. The expired native credential needs its approved host maintenance workflow; a reporting change does not repair it.

Activity

  1. sumitake commented on Oct 19, 2026

    @sumitake
    OwnerAuthor

    The qualification report now explicitly includes qualification_scope: mechanical_transport_and_source_checks and caller_fixture_acceptance_required: true. The existing qualified predicate, opaque content, statuses, timeout and single-attempt behavior remain unchanged. The reporting clarification passed its offline regression, independent cross-check and required CI, and has merged in the separately governed maintenance tooling.

    The original failed OpenCode case remains preserved and unmet. Approved native credential restoration and one distinct fresh missing-case qualification are still required; release PR #235 remains draft and version 7.0.9 has not been published. This closes the reporting-clarity bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions