EventsCompactionConfig.compaction_interval accepts 0/negative, silently compacting on every invocation

[hiroakis]

🔴 Required Information

Describe the Bug:
EventsCompactionConfig.compaction_interval and overlap_size are declared as plain required ints with no value constraints, unlike their sibling fields token_threshold (Field(gt=0)) and event_retention_size (Field(ge=0)).

As a result, compaction_interval=0 (or a negative value) is silently accepted and makes the sliding-window compaction trigger fire on every invocation. In _run_compaction_for_sliding_window (src/google/adk/apps/compaction.py) the guard

if len(new_invocation_ids) < config.compaction_interval:
    return None  # Not enough new invocations to trigger compaction.

can never be true when compaction_interval <= 0, so compaction runs after every invocation instead of being throttled.

This is also confusing because 0 means different things for the two sliding-window fields: overlap_size=0 is a valid "no overlap", but compaction_interval=0 is a degenerate "fire every time" (not "disable").

Steps to Reproduce:

1. pip install google-adk
2. Run the snippet below (or construct an App with events_compaction_config=EventsCompactionConfig(compaction_interval=0, overlap_size=0, summarizer=...)).
3. Observe that construction succeeds with compaction_interval=0.
4. With such a config, sliding-window compaction fires on every invocation.

Expected Behavior:
compaction_interval=0 (and negative values) should be rejected at construction time with a ValidationError, consistent with token_threshold (gt=0) and event_retention_size (ge=0). overlap_size should allow 0 (no overlap) but reject negatives.

Observed Behavior:
EventsCompactionConfig(compaction_interval=0, overlap_size=0) is accepted with no error, and downstream causes compaction to run on every invocation.

Environment Details:

• ADK Library Version (pip show google-adk): 2.4.0
• Desktop OS: macOS
• Python Version (python -V): 3.10

Model Information:

• Are you using LiteLLM: No
• Which model is being used: N/A (configuration-validation bug, model-agnostic)

---

🟡 Optional Information

Regression:
N/A — appears to have been present since EventsCompactionConfig was introduced.

Additional Context:
Suggested fix (small, mirrors the existing validated sibling fields):

• compaction_interval: int = Field(gt=0)
• overlap_size: int = Field(ge=0) (0 = no overlap, still valid)

Happy to send a PR with tests.

Separately (tracked as a feature request, not this bug): because compaction_interval / overlap_size are required, there is currently no clean way to enable only the token-threshold trigger without setting compaction_interval to a large sentinel value.

Minimal Reproduction Code:

from google.adk.apps.app import EventsCompactionConfig

# Accepted today (no error); makes sliding-window compaction fire every invocation.
cfg = EventsCompactionConfig(compaction_interval=0, overlap_size=0)
print(cfg.compaction_interval)  # -> 0

# Negative is also accepted today.
EventsCompactionConfig(compaction_interval=-1, overlap_size=0)

How often has this issue occurred?:

• Always (100%)

[surajksharma07]

@hiroakis
Ran your repro locally and confirmed compaction_interval=0/-1 slip through today exactly as described.
Also tried the Field(gt=0)/Field(ge=0) approach in isolation and it correctly rejects the bad values while leaving valid configs untouched.

Since you've already got #6399 open with tests passing, I'll get that into review rather than asking for a separate fix.

[hiroakis]

@surajksharma07 This looks fixed by ec42cfa, which adds compaction_interval gt=0 and overlap_size ge=0 validation (so compaction_interval <= 0 and a negative overlap_size now raise ValidationError). May I closing as resolved?

[surajksharma07]

Confirmed, @hiroakis — reran your exact repro against main and both compaction_interval=0 and -1 now raise ValidationError, so ec42cfa does cover this.

Worth noting how it landed though: that commit was actually for #6398 (making the sliding-window fields Optional, plus a "set together"/"at least one trigger" validator) and picked up the gt=0/ge=0 bounds as part of that, rather than through #6399's approach of keeping them required.
So #6399 is superseded at this point and would conflict with the current field shape if merged as-is — I'd close it rather than merge, but the bounds you proposed are exactly what shipped, so nice call either way.

Good to close #6397 as resolved!

One caveat: this isn't in CHANGELOG.md yet, so it's fixed on main but hasn't hit a release — will land in the next cut, not the current PyPI package.