Skip to content

Make EventsCompactionConfig sliding-window fields optional (enable a single trigger without a sentinel) #6398

Description

@hiroakis

🔴 Required Information

Is your feature request related to a specific problem?

EventsCompactionConfig has two independent compaction triggers:

  • token-threshold: token_threshold + event_retention_size (both Optional, must be set together)
  • sliding-window: compaction_interval + overlap_size (both required int)

Because the sliding-window fields are required, there is no clean way to enable only the token-threshold trigger and turn the sliding-window trigger off. Today I have to set compaction_interval to a large sentinel value (e.g. 1_000_000) so the guard len(new_invocation_ids) < compaction_interval never fires — a hack that hides intent and is easy to get wrong (0 does the opposite: fire every invocation).

For a cost-driven use case, the token-threshold trigger is precisely coupled to the signal we care about (prompt size), whereas the invocation-count-based sliding-window trigger fires regardless of token size and can summarize unnecessarily. So being able to enable just one trigger is genuinely useful.

Describe the Solution You'd Like

Make compaction_interval + overlap_size an optional pair, mirroring the existing token_threshold + event_retention_size pair:

  • compaction_interval: Optional[int] = Field(default=None, gt=0)
  • overlap_size: Optional[int] = Field(default=None, ge=0)
  • A model_validator requiring the two to be set together (or both None), matching _validate_token_params.
  • Require that at least one trigger (token-threshold pair OR sliding-window pair) is configured.

This lets users opt into a single trigger system without a sentinel value:

# token-threshold only
EventsCompactionConfig(
    summarizer=...,
    token_threshold=160_000,
    event_retention_size=50,
)  # no compaction_interval / overlap_size needed

This is a public-API change, so raising it here for direction before opening a PR. (A separate, smaller bug report covers adding gt=0 / ge=0 validation to the currently-required fields.)

Impact on your work

We run an ADK-based gateway where a few long tool-heavy sessions drive the vast majority of Gemini input-token cost. We want token-threshold compaction only. Today we must pass a 1_000_000 sentinel to disable the sliding-window trigger, which is unclear to readers and a foot-gun (0 silently means "every invocation"). An optional pair would make the intended configuration self-documenting and safe. Not time-critical, but it would simplify our config and likely help others with cost-oriented setups.

Metadata

Metadata

Assignees

Labels

agent config[Component] This issue is related to the Agent Config interface and implementationneeds review[Status] The PR/issue is awaiting review from the maintainer

Fields

No fields configured for Feature.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions