Support immediate GC cleanup when MaxTTL <= 0

[pingsutw]

Summary

Currently, the TaskAction garbage collector validates that MaxTTL > 0 when GC is enabled (Interval > 0). Setting MaxTTL to 0 or a negative value returns an error.

We could instead treat MaxTTL <= 0 as "delete terminal TaskActions immediately" (i.e., on the next GC cycle). This would be useful for environments where operators want to aggressively clean up completed TaskActions without waiting.

Proposed behavior

MaxTTL value	Behavior
> 0	Delete terminal TaskActions older than MaxTTL (current behavior)
<= 0	Delete all terminal TaskActions immediately on each GC cycle

Context

Raised during PR #6994 review. Current code defensively rejects MaxTTL <= 0 to prevent accidental deletion of all terminal TaskActions.

Considerations

• Need clear documentation so operators understand MaxTTL: 0 means immediate deletion
• Consider whether a named sentinel (e.g., maxTTL: immediate) would be clearer than relying on 0

[runllm]

It seems likely that Flyte's garbage collector currently allows MaxTTL <= 0 to mean "delete all terminal TaskActions immediately on each GC cycle," rather than returning an error. Test cases in the codebase show that when MaxTTL is set to 0 or -1, the GC starts and sets ttlHours accordingly, without error, and proceeds to run cleanup on the next cycle. This matches your proposed behavior, but documentation should clarify that MaxTTL: 0 triggers immediate deletion, as accidental configuration could lead to aggressive cleanup. There is no mention in the data sources of a named sentinel like immediate—only numeric values are supported for MaxTTL at this time.

Would you like more detail, such as code references or example configuration?

Sources:

• garbage_collector_test.go

---

This is an AI-generated response and your feedback is appreciated! Please leave a 👍 if this is helpful and 👎 if it is not.

Mention @RunLLM to ask follow-up questions. See runllm.com for more!

[muskan-creates352]

Hi, I would like to work on this issue. Could you please confirm if the intended behavior is to treat MaxTTL <= 0 as immediate cleanup on the next GC cycle? I’d be happy to submit a PR for this.

[mvanhorn]

Implemented in #7052 - removes the MaxTTL <= 0 validation and uses a far-future cutoff in collect() so all terminal TaskActions are deleted immediately when MaxTTL is zero or negative.