fix: logging error with more than 1k characters #970
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.
Fix logging error with more than 1k characters:
Description:
Motivation:
Related Issues:
The simplest and most effective fix is to set MAX_RESPONSE_LENGTH to a higher, practical value that accommodates typical LLM outputs while keeping log messages manageable for broadcasting to clients via WebSockets. However, we must also modify the code to prevent parsing errors when truncation occurs. Here’s why and how:
Why Not Remove the Check? While removing the length check would log full responses, it risks sending extremely large messages (e.g., megabytes) to clients, potentially causing performance issues in WebSocket communication or client handling. A reasonable limit provides balance.
Why a Higher Limit? LLM outputs can easily exceed 1000 characters. For example, a 4096-token response (a common max for models like GPT-3) might translate to ~16,000 characters or more in JSON form, including metadata. A higher limit ensures most responses are logged fully.
Why Fix Truncation? Even with a higher limit, responses exceeding it must be handled gracefully to avoid invalid JSON errors.
Setting MAX_RESPONSE_LENGTH to 100,000 characters (~100KB):
Covers Most Cases: This captures full responses for most LLM outputs, including lengthy ones up to tens of thousands of characters, while accounting for JSON overhead (e.g., keys, quotes).
WebSocket Friendly: Modern WebSocket implementations, including in Cloudflare Workers (where your app runs with workerd), support messages up to 1MB. At ~100KB, this is well within limits and safe for broadcasting.
Practical for Logging: It balances completeness with preventing excessively large log entries.