Copilot commented on code in PR #13323:
URL: https://github.com/apache/apisix/pull/13323#discussion_r3166529313
##########
apisix/plugins/ai-providers/base.lua:
##########
@@ -384,6 +385,7 @@ function _M.parse_streaming_response(self, ctx, res,
target_proto, converter, co
res._httpc:close()
res._httpc = nil
end
+ res._upstream_bytes = bytes_read
ctx.var.llm_request_done = true
end
Review Comment:
In `abort_on_disconnect()`, `bytes_read` is referenced before it is declared
(`local bytes_read = 0` is defined later). In Lua, locals are only in-scope
from their declaration onward, so this will resolve to a global (likely nil)
and can leave `res._upstream_bytes` unset, making `$upstream_response_length`
fall back to 0 on client disconnects. Declare `local bytes_read` before
defining `abort_on_disconnect` (or move the `local bytes_read = 0`
initialization above the function) so the closure captures the intended local
variable.
##########
apisix/plugins/ai-providers/base.lua:
##########
@@ -309,6 +309,7 @@ function _M.parse_response(self, ctx, res, client_proto,
converter, conf)
core.log.warn("failed to read response body: ", err)
return nil, err
end
+ res._upstream_bytes = #raw_res_body
ngx.status = res.status
Review Comment:
When `max_response_bytes` is set, the early-return path that aborts mid-read
on `total > max_bytes` returns before `res._upstream_bytes` is assigned. That
means the final `update_upstream_state()` will log `response_length` as 0 even
though some bytes were already read from upstream. Consider setting
`res._upstream_bytes` to the number of bytes read so far (e.g., `total`)
immediately before returning in that abort branch.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
