[Bug]: Attachment capacity admission fails before automatic compaction in long sessions #1394

OpenSquilla version or commit

0.5.3 / b3ef93a7522aeb3aa3ae43dc69c485e6983c2729

Area

Gateway

Reproduction steps

1. Enable SquillaRouter with a catalog-known image tier. In this reproduction, the image tier was tokenrhythm / kimi-k2.6; the live deployment catalog reported a 256,000-token context window and 128,000 max output tokens.
2. Use a long, tool-heavy chat session. A first small image attachment (about 65 KB) succeeds and the turn runs for several minutes with multiple tool calls.
3. In the same session, send another small image attachment (1000 x 728 PNG, 66,843 bytes).
4. Observe that SquillaRouter selects the image tier, then immediately raises LargeContextCapacityError before any provider request is made:

No SquillaRouter deployment has proven capacity for the complete attachment request. For a custom or catalog-unknown model, set llm.context_window_tokens to the deployment's verified context limit.

The second image is approximately the same size as the first one. The relevant difference is that the durable session history grew substantially during the preceding tool-heavy turn.

Expected behavior

When all of the following are true:

• the target deployment's context limit is proven by catalog/config;
• admission fails because the complete request, including durable history, exceeds the known safe input budget; and
• compaction is enabled and eligible;

OpenSquilla should attempt automatic compaction once, rebuild the complete request estimate, and rerun attachment capacity admission. If the compacted request still does not fit, it should fail closed with an actionable error.

Capacity-unknown deployments should continue to fail closed and should not be made eligible merely by compaction.

Actual behavior

finalize_squilla_router_capacity() runs before history loading/compaction. It uses the seeded replay estimate for the complete request; when no capacity-safe tier is found, it marks large_context_capacity_blocked, and apply_model_override() throws before the normal context-compaction path can run.

In this reproduction:

• the request was routed to the catalog-known image tier;
• the error occurred only milliseconds after routing;
• the persisted turn error had no executed provider/model and no provider failure kind, confirming that the provider was never called;
• the generic custom/catalog-unknown configuration hint was shown even though this deployment was present in the live catalog.

This makes a recoverable long-history condition look like a deployment configuration problem. The immediate workaround is manual /compact or starting a new session.

Suggested implementation shape

• Distinguish at least capacity_unknown from known_capacity_request_too_large in admission results instead of collapsing both into False.
• For known_capacity_request_too_large, schedule/perform one guarded compaction attempt using the selected attachment route's physical deployment limits.
• After compaction completes, rebuild the history/request estimate and rerun final capacity admission exactly once.
• Preserve the current user turn and attachments across compaction.
• Prevent retry loops and retain the existing fail-closed behavior if compaction is skipped, fails, or still cannot prove capacity.
• Update the user-facing error to recommend /compact or a new session when history pressure is the cause; reserve the llm.context_window_tokens hint for genuinely unknown custom deployments.

Potential risk: automatic compaction changes the durable history representation and adds latency/provider cost. The retry should therefore be bounded, observable, and restricted to the case where known-capacity re-admission can plausibly succeed.

Environment

macOS desktop app, embedded Gateway, OpenSquilla 0.5.3

Diagnostic bundle and error reference

ref: ffe5dd90

No bundle attached because it may include unrelated local session data. The reproduction details above are sanitized.

Related issues

• [Bug]: compact功能异常，上下文超长时仍无法触发 #1087: manual/automatic compaction threshold behavior
• [Bug]: SystemError: The request is too large for the provider context window after automatic context compaction and payload reduction. OpenSquilla preserved the recoverable state; retry with a narrower request or a larger-context model. (ref: c80f5a3c) #618: request remains too large after automatic compaction and payload reduction
• SystemError: Provider returned no visible response for large input during compaction #742: provider returns no visible response during compaction