kaxil commented on code in PR #67890:
URL: https://github.com/apache/airflow/pull/67890#discussion_r3342964855
##########
airflow-core/src/airflow/api_fastapi/core_api/routes/public/task_store.py:
##########
@@ -61,7 +61,13 @@ def _resolve_expires_at(expires_at: datetime | None |
Literal["default"]) -> dat
"""
if expires_at == "default":
days = conf.getint("state_store", "default_retention_days")
- return datetime.now(tz=timezone.utc) + timedelta(days=days)
+ if days < 0:
+ raise HTTPException(
+ status_code=status.HTTP_400_BAD_REQUEST,
+ detail=f"[state_store] default_retention_days must be >= 0,
got {days}. "
+ "Set to 0 to disable expiry.",
+ )
+ return None if days == 0 else datetime.now(tz=timezone.utc) +
timedelta(days=days)
Review Comment:
This branch also changes the `days == 0` behavior: it used to return `now +
timedelta(days=days)`, so `days=0` gave `expires_at = now` and rows expired
immediately, and now it returns `None` (never expire). That matches the SDK
path and the config doc ("Set to 0 to disable expiry"), so it looks
intentional. Since it's a separate change from the negative-days fix in the
title, should it be called out in the description and changelog so it's clear
that `expires_at="default"` + `default_retention_days=0` no longer expires rows
on the API path?
##########
task-sdk/src/airflow/sdk/execution_time/context.py:
##########
@@ -558,7 +558,12 @@ def set(self, key: str, value: JsonValue, *, retention:
timedelta | None = None)
expires_at = now + retention
else:
days = conf.getint("state_store", "default_retention_days")
- expires_at = None if days <= 0 else now + timedelta(days=days)
+ if days < 0:
Review Comment:
`default_retention_days` is a deploy-wide static setting, so a negative
value is a misconfig that's identical for every task. Validating it here means
the error only surfaces when a task actually calls `set(retention=None)`, and
on the SDK side it shows up as a task failure mid-run rather than at startup.
Did you consider validating once at config load so a bad value fails the
deployment early instead? Not blocking, the per-write check is already better
than the silent corruption it replaces, just curious about the trade-off.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
