github-actions[bot] commented on code in PR #64329:
URL: https://github.com/apache/doris/pull/64329#discussion_r3382041677
##########
.github/scripts/emit_litefuse_otel_io.py:
##########
@@ -622,21 +644,51 @@ def post_payload_once(endpoint, public_key, secret_key,
payload):
}
+def retry_payload_chunks_after_413(payload, request_size, max_payload_bytes):
+ batch = payload.get("batch") or []
+ if not batch:
+ raise RuntimeError(
+ "Litefuse ingestion returned 413 for an empty payload chunk"
+ )
+
+ next_limit = max(1_000, min(max_payload_bytes - 1, request_size // 2))
Review Comment:
This retry limit is not guaranteed to make progress. If the endpoint keeps
returning 413 for a chunk whose serialized size is already below about 2 KB,
`request_size // 2` falls below the 1,000-byte floor, so `next_limit` stays at
1,000 and `chunk_payload()` can regenerate the same multi-event chunk.
`post_payload()` then prepends that same chunk and loops forever. A concrete
case is a caller using a very small accepted body size, or any proxy/Litefuse
response that keeps returning 413 below this floor. Please make each retry
strictly reduce the current request size, or detect no-progress and fail with a
clear error instead of retrying indefinitely.
##########
.github/scripts/emit_litefuse_otel_io.py:
##########
@@ -673,16 +725,30 @@ def fetch_observations_v2(base_url, public_key,
secret_key, trace_id):
return json.loads(response.read().decode())
-def fetch_observations_legacy(base_url, public_key, secret_key, trace_id):
+def fetch_observations_legacy(
+ base_url, public_key, secret_key, trace_id, max_pages=10
Review Comment:
The fixed `max_pages=10` leaves the original readback problem in place for
traces with more than 1,000 observations. If page 10 is full, this returns a
truncated observation list without any signal; for large reviews the first
`codex.agent_message` carrying `turn_input` can still be on a later page, so
verification can either fail even though upload succeeded or pass after reading
an incomplete trace. Please continue paging until the API reports no more rows,
or fail explicitly when a safety cap is reached and include that truncation in
the diagnostic.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
