Two defects in the image output counter could inflate imageCount for
text-only responses, causing per-image charges instead of token billing:
1. addDataArray counted every element in a top-level "data" array
without checking whether each element contained actual image output
(url/b64_json). Non-image objects in a "data" array are now skipped.
2. addImageOutputItem accepted image_generation.completed items with
no result/b64_json/url, inflating the count. These items are now
filtered the same way as every other item type.
Fixes#3196
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
LegalDocumentView.vue (admin-compliance acknowledgement gate) build-time
imports ../../../../docs/legal/*.md?raw. The Docker image build broke
because the frontend-builder stage only COPYs frontend/ (never docs/) and
.dockerignore excludes both docs/ and *.md from the build context.
Upstream CI runs `pnpm build` from the repo root (docs/ resolvable via
../docs/) and never exercises the Docker path, so this stayed hidden until
the buildkit package job surfaced "Could not resolve docs/legal/...md?raw".
Fix:
- COPY docs/legal/ into /app/docs/legal in Dockerfile and deploy/Dockerfile
so it sits beside /app/frontend (WORKDIR), matching the relative import.
Only the required subtree is copied to keep the build dependency minimal.
- Re-include docs/legal/*.md in .dockerignore so buildkit ships the subtree.
apiToForm read bedrock_cc_compat as Record<string, boolean> (nested map)
but formToAPI saves it as a plain bool. Reading true["anthropic"] returns
undefined, so the toggle always appeared off after save.
Align the read path with the write path: fc?.bedrock_cc_compat === true.
Move anthropic-beta header filtering from separate FilterBedrockBetaHeader
into ApplyBedrockCCCompat, so one function handles all CC compat processing
(body cleanup + header filtering). Change signature from ctx to *gin.Context
to access request headers. Remove the redundant separate call in handler.
- Remove `provider` and `metadata` fields from Bedrock request body.
Bedrock returns 400 ValidationException for unknown top-level fields.
- When filtered beta tokens list is empty, delete any pre-existing
`anthropic_beta` field in body to prevent client-injected tokens
from leaking to Bedrock unfiltered.
- Add `context-management-2025-06-27` and `fine-grained-tool-streaming-2025-05-14`
to bedrockSupportedBetaTokens whitelist per AWS documentation.
Service layer writes a complete JSON error response then returns error.
Handler's ensureForwardErrorResponse couldn't distinguish this from
"no response written" and appended an SSE event, corrupting the body.
Use gin.Context flag: service marks MarkResponseCommitted(c) after
writing, ensureForwardErrorResponse checks IsResponseCommitted(c)
and skips. Zero function signature changes, zero error wrapping.
When a Forward implementation already wrote a complete non-SSE (JSON) error
response to the client and returned an error -- e.g. the case-400 passthrough
in GatewayService.handleErrorResponse -- the handler unconditionally called
ensureForwardErrorResponse, which detected the writer was already written and
appended a fallback `data: {"type":"error",...}` SSE frame. The client then
received a corrupted body: the upstream JSON immediately followed by a stray
`data:` line.
Add gatewayForwardErrorAlreadyCommunicated (and the OpenAI counterpart) to
detect this case -- writer size changed AND Content-Type is not
text/event-stream -- and skip the fallback. SSE streams that only flushed
keepalive pings or partial data still receive a protocol-compliant terminal
frame, so strict SDKs (Codex CLI) do not see a silent EOF.
Applied consistently across the Messages / ChatCompletions / Responses
gateway handlers and the OpenAI chat/images handlers. Added regression tests
covering JSON passthrough, mid-stream SSE 400, nil-error and no-write cases.
wangziwenunique