Repository navigation
fix: return HTTP 400 Response for overflow to trigger opencode compaction - #114
Merged
tickernelz merged 1 commit intoJul 23, 2026
Conversation
…tion Previously threw a plain Error for 'input is too long' which bypassed ai-sdk's APICallError handling. OpenCode expects a fetch Response so ai-sdk can convert it to APICallError and match the overflow pattern to trigger automatic context compaction. Now returns a proper 400 Response with context_length_exceeded code that ai-sdk recognizes as an overflow signal.
Owner
|
Merged after validating the exact PR head against the latest The initial integrated suite exposed an unintended regression in the generic non-overflow SDK error contract. I kept the new context-overflow Final merged-tree verification:
|
RvVeen
added a commit
to Servoy/opencode-kiro-auth
that referenced
this pull request
Aug 10, 2026
While rebasing this branch onto upstream/master, three issues surfaced during review that needed fixing on top of the mechanical conflict resolution: 1. Test API drift: the tool-name-registry API on upstream (createToolNameRegistry/restoreToolName, per-request scoped) diverged from this branch's standalone shortenToolName/buildToolNameMaps helpers. Updated tests to use the registry API that survived conflict resolution, and aligned description/schema length expectations with upstream's sanitizeCodeWhispererSchema defaults. Also fixed two tests that assumed pre-upstream ErrorHandler/AccountManager behavior (expiresAt reset on bearer-invalid, markUnhealthy mock) that changed upstream in tickernelz#114. 2. Duplicate/dead code introduced by the rebase: - request-handler.ts's uiEffort budget lookup used its own THINKING_BUDGETS in constants.ts, a scale that disagreed with plugin/effort.ts's version (the one getEffectiveEffort/ budgetToEffort actually use to map a budget back to an effort level for the Kiro wire request). UI 'high' silently became wire 'max' instead of 'high'. Now imports THINKING_BUDGETS from plugin/effort.ts so there is a single source of truth. - withInProcessLock() in locked-operations.ts was exported but never called anywhere — dead code left over from a lock-hardening commit not carried into this branch's account-write path. Removed. - image-cache.ts's defaultCacheDir() duplicated the platform config-dir lookup already in plugin/config/loader.ts (getConfigDir, now exported). Reuses it instead of a fourth copy of the same win32/XDG branching. - request.ts had a redundant DEBUG/OPENCODE_LOG_LEVEL guard around a logger.debug() call that already gates on those env vars internally. 3. Regression: RequestHandler.kiroRequestQueue serializes all Kiro API calls across sessions/workspaces and predates this branch (introduced in 'Match Kiro CLI retry pacing', still present on upstream/master). The session-id extraction change earlier in this branch replaced the enqueueKiroRequest() wrapper in handle() with a direct call to handleKiroRequest(), silently dropping the serialization. Restored the queue with sessionId extracted before enqueueing, so per-session conversation isolation and global request pacing both hold.
RvVeen
added a commit
to Servoy/opencode-kiro-auth
that referenced
this pull request
Aug 10, 2026
While rebasing this branch onto upstream/master, three issues surfaced during review that needed fixing on top of the mechanical conflict resolution: 1. Test API drift: the tool-name-registry API on upstream (createToolNameRegistry/restoreToolName, per-request scoped) diverged from this branch's standalone shortenToolName/buildToolNameMaps helpers. Updated tests to use the registry API that survived conflict resolution, and aligned description/schema length expectations with upstream's sanitizeCodeWhispererSchema defaults. Also fixed two tests that assumed pre-upstream ErrorHandler/AccountManager behavior (expiresAt reset on bearer-invalid, markUnhealthy mock) that changed upstream in tickernelz#114. 2. Duplicate/dead code introduced by the rebase: - request-handler.ts's uiEffort budget lookup used its own THINKING_BUDGETS in constants.ts, a scale that disagreed with plugin/effort.ts's version (the one getEffectiveEffort/ budgetToEffort actually use to map a budget back to an effort level for the Kiro wire request). UI 'high' silently became wire 'max' instead of 'high'. Now imports THINKING_BUDGETS from plugin/effort.ts so there is a single source of truth. - withInProcessLock() in locked-operations.ts was exported but never called anywhere — dead code left over from a lock-hardening commit not carried into this branch's account-write path. Removed. - image-cache.ts's defaultCacheDir() duplicated the platform config-dir lookup already in plugin/config/loader.ts (getConfigDir, now exported). Reuses it instead of a fourth copy of the same win32/XDG branching. - request.ts had a redundant DEBUG/OPENCODE_LOG_LEVEL guard around a logger.debug() call that already gates on those env vars internally. 3. Regression: RequestHandler.kiroRequestQueue serializes all Kiro API calls across sessions/workspaces and predates this branch (introduced in 'Match Kiro CLI retry pacing', still present on upstream/master). The session-id extraction change earlier in this branch replaced the enqueueKiroRequest() wrapper in handle() with a direct call to handleKiroRequest(), silently dropping the serialization. Restored the queue with sessionId extracted before enqueueing, so per-session conversation isolation and global request pacing both hold.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Problem
When Kiro API returns "Input is too long" (400), the plugin was throwing a plain
Error. This bypassed ai-sdk'sAPICallErrorhandling, so OpenCode never recognized it as a context overflow and never triggered automatic compaction.Solution
Return a proper HTTP 400
Responseobject with:message: "input is too long for requested model"(matches OpenCode's overflow pattern)type: "invalid_request_error"code: "context_length_exceeded"This allows ai-sdk to convert it into an
APICallError, which OpenCode then pattern-matches to trigger compaction retry.Testing