Honor the API server Dag cache TTL when no size limit is set by jason810496 · Pull Request #71814 · apache/airflow

jason810496 · 2026-08-19T05:54:41Z

stacked with: Report Dag cache metrics under each component's own namespace #71815, Make the scheduler Dag cache size and TTL configurable #71816

[api] dag_cache_size = 0 reads as "no size limit", but it selected a mapping that never evicted and silently ignored [api] dag_cache_ttl. Age-based eviction could only be enabled by also accepting a size cap.

A TTL now applies with or without a size limit; only setting both options to 0 disables eviction. Deployments on dag_cache_size = 0 start evicting on the default hour-long TTL — set dag_cache_ttl = 0 to keep the old behaviour.

Also corrects the documented version_added for both options: 3.2.2, not 3.3.0.

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

uranusjr · 2026-08-19T08:54:39Z

We should probably add a news fragment to the behavioral change when dag_cache_size = 0 since it’s visible to the user. The change is justified as a bug fix, but the fix may in turn cause issues in existing deployments.

uranusjr

A few nits.

`[api] dag_cache_size = 0` reads as "no size limit", but it selected a mapping that never evicted at all and silently ignored `[api] dag_cache_ttl`. Age-based eviction could therefore only be enabled by also accepting a size cap, which is backwards for a deployment that wants to bound staleness rather than count. A TTL now applies with or without a size limit, and only setting both options to 0 disables eviction. Deployments on `dag_cache_size = 0` start evicting on the default hour-long TTL; setting `dag_cache_ttl = 0` restores the old behaviour. The options were also documented as added in 3.3.0. They shipped in 3.2.2.

Negative cache configuration should fail fast, and operator guidance must reflect that TTL refreshes happen only at revalidation boundaries.

Copilot

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

Validating at the shared boundary prevents non-API callers from silently clamping invalid cache settings.

Context-specific errors help operators identify invalid API settings, while defensive constructor checks protect other callers and documentation remains compatible with the spellchecker.

jason810496

We should probably add a news fragment to the behavioral change when dag_cache_size = 0 since it’s visible to the user. The change is justified as a bug fix, but the fix may in turn cause issues in existing deployments.

Thanks TP for the review. I’ve resolved all the comments, and it makes sense to add the new fragment.

…set (#71814) (#71845) * Honor the API server Dag cache TTL when no size limit is set `[api] dag_cache_size = 0` reads as "no size limit", but it selected a mapping that never evicted at all and silently ignored `[api] dag_cache_ttl`. Age-based eviction could therefore only be enabled by also accepting a size cap, which is backwards for a deployment that wants to bound staleness rather than count. A TTL now applies with or without a size limit, and only setting both options to 0 disables eviction. Deployments on `dag_cache_size = 0` start evicting on the default hour-long TTL; setting `dag_cache_ttl = 0` restores the old behaviour. The options were also documented as added in 3.3.0. They shipped in 3.2.2. * Reject negative API Dag cache values and clarify TTL behavior Negative cache configuration should fail fast, and operator guidance must reflect that TTL refreshes happen only at revalidation boundaries. * Reject negative cache values for every DBDagBag caller Validating at the shared boundary prevents non-API callers from silently clamping invalid cache settings. * Clarify cache validation context and docs wording Context-specific errors help operators identify invalid API settings, while defensive constructor checks protect other callers and documentation remains compatible with the spellchecker. * Clarify API cache TTL documentation layout (cherry picked from commit f63d321)

jason810496 · 2026-08-19T05:54:41Z

stacked with: Report Dag cache metrics under each component's own namespace #71815, Make the scheduler Dag cache size and TTL configurable #71816

[api] dag_cache_size = 0 reads as "no size limit", but it selected a mapping that never evicted and silently ignored [api] dag_cache_ttl. Age-based eviction could only be enabled by also accepting a size cap.

A TTL now applies with or without a size limit; only setting both options to 0 disables eviction. Deployments on dag_cache_size = 0 start evicting on the default hour-long TTL — set dag_cache_ttl = 0 to keep the old behaviour.

Also corrects the documented version_added for both options: 3.2.2, not 3.3.0.

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

uranusjr · 2026-08-19T08:54:39Z

We should probably add a news fragment to the behavioral change when dag_cache_size = 0 since it’s visible to the user. The change is justified as a bug fix, but the fix may in turn cause issues in existing deployments.

uranusjr

A few nits.

`[api] dag_cache_size = 0` reads as "no size limit", but it selected a mapping that never evicted at all and silently ignored `[api] dag_cache_ttl`. Age-based eviction could therefore only be enabled by also accepting a size cap, which is backwards for a deployment that wants to bound staleness rather than count. A TTL now applies with or without a size limit, and only setting both options to 0 disables eviction. Deployments on `dag_cache_size = 0` start evicting on the default hour-long TTL; setting `dag_cache_ttl = 0` restores the old behaviour. The options were also documented as added in 3.3.0. They shipped in 3.2.2.

Negative cache configuration should fail fast, and operator guidance must reflect that TTL refreshes happen only at revalidation boundaries.

Copilot

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

Validating at the shared boundary prevents non-API callers from silently clamping invalid cache settings.

Context-specific errors help operators identify invalid API settings, while defensive constructor checks protect other callers and documentation remains compatible with the spellchecker.

jason810496

We should probably add a news fragment to the behavioral change when dag_cache_size = 0 since it’s visible to the user. The change is justified as a bug fix, but the fix may in turn cause issues in existing deployments.

Thanks TP for the review. I’ve resolved all the comments, and it makes sense to add the new fragment.

…set (#71814) (#71845) * Honor the API server Dag cache TTL when no size limit is set `[api] dag_cache_size = 0` reads as "no size limit", but it selected a mapping that never evicted at all and silently ignored `[api] dag_cache_ttl`. Age-based eviction could therefore only be enabled by also accepting a size cap, which is backwards for a deployment that wants to bound staleness rather than count. A TTL now applies with or without a size limit, and only setting both options to 0 disables eviction. Deployments on `dag_cache_size = 0` start evicting on the default hour-long TTL; setting `dag_cache_ttl = 0` restores the old behaviour. The options were also documented as added in 3.3.0. They shipped in 3.2.2. * Reject negative API Dag cache values and clarify TTL behavior Negative cache configuration should fail fast, and operator guidance must reflect that TTL refreshes happen only at revalidation boundaries. * Reject negative cache values for every DBDagBag caller Validating at the shared boundary prevents non-API callers from silently clamping invalid cache settings. * Clarify cache validation context and docs wording Context-specific errors help operators identify invalid API settings, while defensive constructor checks protect other callers and documentation remains compatible with the spellchecker. * Clarify API cache TTL documentation layout (cherry picked from commit f63d321)

jason810496 · 2026-08-19T05:54:41Z

stacked with: Report Dag cache metrics under each component's own namespace #71815, Make the scheduler Dag cache size and TTL configurable #71816

[api] dag_cache_size = 0 reads as "no size limit", but it selected a mapping that never evicted and silently ignored [api] dag_cache_ttl. Age-based eviction could only be enabled by also accepting a size cap.

A TTL now applies with or without a size limit; only setting both options to 0 disables eviction. Deployments on dag_cache_size = 0 start evicting on the default hour-long TTL — set dag_cache_ttl = 0 to keep the old behaviour.

Also corrects the documented version_added for both options: 3.2.2, not 3.3.0.

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

uranusjr · 2026-08-19T08:54:39Z

We should probably add a news fragment to the behavioral change when dag_cache_size = 0 since it’s visible to the user. The change is justified as a bug fix, but the fix may in turn cause issues in existing deployments.

uranusjr

A few nits.

`[api] dag_cache_size = 0` reads as "no size limit", but it selected a mapping that never evicted at all and silently ignored `[api] dag_cache_ttl`. Age-based eviction could therefore only be enabled by also accepting a size cap, which is backwards for a deployment that wants to bound staleness rather than count. A TTL now applies with or without a size limit, and only setting both options to 0 disables eviction. Deployments on `dag_cache_size = 0` start evicting on the default hour-long TTL; setting `dag_cache_ttl = 0` restores the old behaviour. The options were also documented as added in 3.3.0. They shipped in 3.2.2.

Negative cache configuration should fail fast, and operator guidance must reflect that TTL refreshes happen only at revalidation boundaries.

Copilot

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

Validating at the shared boundary prevents non-API callers from silently clamping invalid cache settings.

Context-specific errors help operators identify invalid API settings, while defensive constructor checks protect other callers and documentation remains compatible with the spellchecker.

jason810496

We should probably add a news fragment to the behavioral change when dag_cache_size = 0 since it’s visible to the user. The change is justified as a bug fix, but the fix may in turn cause issues in existing deployments.

Thanks TP for the review. I’ve resolved all the comments, and it makes sense to add the new fragment.

…set (#71814) (#71845) * Honor the API server Dag cache TTL when no size limit is set `[api] dag_cache_size = 0` reads as "no size limit", but it selected a mapping that never evicted at all and silently ignored `[api] dag_cache_ttl`. Age-based eviction could therefore only be enabled by also accepting a size cap, which is backwards for a deployment that wants to bound staleness rather than count. A TTL now applies with or without a size limit, and only setting both options to 0 disables eviction. Deployments on `dag_cache_size = 0` start evicting on the default hour-long TTL; setting `dag_cache_ttl = 0` restores the old behaviour. The options were also documented as added in 3.3.0. They shipped in 3.2.2. * Reject negative API Dag cache values and clarify TTL behavior Negative cache configuration should fail fast, and operator guidance must reflect that TTL refreshes happen only at revalidation boundaries. * Reject negative cache values for every DBDagBag caller Validating at the shared boundary prevents non-API callers from silently clamping invalid cache settings. * Clarify cache validation context and docs wording Context-specific errors help operators identify invalid API settings, while defensive constructor checks protect other callers and documentation remains compatible with the spellchecker. * Clarify API cache TTL documentation layout (cherry picked from commit f63d321)

jason810496 · 2026-08-19T05:54:41Z

stacked with: Report Dag cache metrics under each component's own namespace #71815, Make the scheduler Dag cache size and TTL configurable #71816

[api] dag_cache_size = 0 reads as "no size limit", but it selected a mapping that never evicted and silently ignored [api] dag_cache_ttl. Age-based eviction could only be enabled by also accepting a size cap.

A TTL now applies with or without a size limit; only setting both options to 0 disables eviction. Deployments on dag_cache_size = 0 start evicting on the default hour-long TTL — set dag_cache_ttl = 0 to keep the old behaviour.

Also corrects the documented version_added for both options: 3.2.2, not 3.3.0.

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

uranusjr · 2026-08-19T08:54:39Z

We should probably add a news fragment to the behavioral change when dag_cache_size = 0 since it’s visible to the user. The change is justified as a bug fix, but the fix may in turn cause issues in existing deployments.

uranusjr

A few nits.

`[api] dag_cache_size = 0` reads as "no size limit", but it selected a mapping that never evicted at all and silently ignored `[api] dag_cache_ttl`. Age-based eviction could therefore only be enabled by also accepting a size cap, which is backwards for a deployment that wants to bound staleness rather than count. A TTL now applies with or without a size limit, and only setting both options to 0 disables eviction. Deployments on `dag_cache_size = 0` start evicting on the default hour-long TTL; setting `dag_cache_ttl = 0` restores the old behaviour. The options were also documented as added in 3.3.0. They shipped in 3.2.2.

Negative cache configuration should fail fast, and operator guidance must reflect that TTL refreshes happen only at revalidation boundaries.

Copilot

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

Validating at the shared boundary prevents non-API callers from silently clamping invalid cache settings.

Context-specific errors help operators identify invalid API settings, while defensive constructor checks protect other callers and documentation remains compatible with the spellchecker.

jason810496

We should probably add a news fragment to the behavioral change when dag_cache_size = 0 since it’s visible to the user. The change is justified as a bug fix, but the fix may in turn cause issues in existing deployments.

Thanks TP for the review. I’ve resolved all the comments, and it makes sense to add the new fragment.

…set (#71814) (#71845) * Honor the API server Dag cache TTL when no size limit is set `[api] dag_cache_size = 0` reads as "no size limit", but it selected a mapping that never evicted at all and silently ignored `[api] dag_cache_ttl`. Age-based eviction could therefore only be enabled by also accepting a size cap, which is backwards for a deployment that wants to bound staleness rather than count. A TTL now applies with or without a size limit, and only setting both options to 0 disables eviction. Deployments on `dag_cache_size = 0` start evicting on the default hour-long TTL; setting `dag_cache_ttl = 0` restores the old behaviour. The options were also documented as added in 3.3.0. They shipped in 3.2.2. * Reject negative API Dag cache values and clarify TTL behavior Negative cache configuration should fail fast, and operator guidance must reflect that TTL refreshes happen only at revalidation boundaries. * Reject negative cache values for every DBDagBag caller Validating at the shared boundary prevents non-API callers from silently clamping invalid cache settings. * Clarify cache validation context and docs wording Context-specific errors help operators identify invalid API settings, while defensive constructor checks protect other callers and documentation remains compatible with the spellchecker. * Clarify API cache TTL documentation layout (cherry picked from commit f63d321)

jason810496 · 2026-08-19T05:54:41Z

stacked with: Report Dag cache metrics under each component's own namespace #71815, Make the scheduler Dag cache size and TTL configurable #71816

[api] dag_cache_size = 0 reads as "no size limit", but it selected a mapping that never evicted and silently ignored [api] dag_cache_ttl. Age-based eviction could only be enabled by also accepting a size cap.

A TTL now applies with or without a size limit; only setting both options to 0 disables eviction. Deployments on dag_cache_size = 0 start evicting on the default hour-long TTL — set dag_cache_ttl = 0 to keep the old behaviour.

Also corrects the documented version_added for both options: 3.2.2, not 3.3.0.

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

uranusjr · 2026-08-19T08:54:39Z

We should probably add a news fragment to the behavioral change when dag_cache_size = 0 since it’s visible to the user. The change is justified as a bug fix, but the fix may in turn cause issues in existing deployments.

uranusjr

A few nits.

`[api] dag_cache_size = 0` reads as "no size limit", but it selected a mapping that never evicted at all and silently ignored `[api] dag_cache_ttl`. Age-based eviction could therefore only be enabled by also accepting a size cap, which is backwards for a deployment that wants to bound staleness rather than count. A TTL now applies with or without a size limit, and only setting both options to 0 disables eviction. Deployments on `dag_cache_size = 0` start evicting on the default hour-long TTL; setting `dag_cache_ttl = 0` restores the old behaviour. The options were also documented as added in 3.3.0. They shipped in 3.2.2.

Negative cache configuration should fail fast, and operator guidance must reflect that TTL refreshes happen only at revalidation boundaries.

Copilot

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

Validating at the shared boundary prevents non-API callers from silently clamping invalid cache settings.

Context-specific errors help operators identify invalid API settings, while defensive constructor checks protect other callers and documentation remains compatible with the spellchecker.

jason810496

We should probably add a news fragment to the behavioral change when dag_cache_size = 0 since it’s visible to the user. The change is justified as a bug fix, but the fix may in turn cause issues in existing deployments.

Thanks TP for the review. I’ve resolved all the comments, and it makes sense to add the new fragment.

…set (#71814) (#71845) * Honor the API server Dag cache TTL when no size limit is set `[api] dag_cache_size = 0` reads as "no size limit", but it selected a mapping that never evicted at all and silently ignored `[api] dag_cache_ttl`. Age-based eviction could therefore only be enabled by also accepting a size cap, which is backwards for a deployment that wants to bound staleness rather than count. A TTL now applies with or without a size limit, and only setting both options to 0 disables eviction. Deployments on `dag_cache_size = 0` start evicting on the default hour-long TTL; setting `dag_cache_ttl = 0` restores the old behaviour. The options were also documented as added in 3.3.0. They shipped in 3.2.2. * Reject negative API Dag cache values and clarify TTL behavior Negative cache configuration should fail fast, and operator guidance must reflect that TTL refreshes happen only at revalidation boundaries. * Reject negative cache values for every DBDagBag caller Validating at the shared boundary prevents non-API callers from silently clamping invalid cache settings. * Clarify cache validation context and docs wording Context-specific errors help operators identify invalid API settings, while defensive constructor checks protect other callers and documentation remains compatible with the spellchecker. * Clarify API cache TTL documentation layout (cherry picked from commit f63d321)

jason810496 · 2026-08-19T05:54:41Z

stacked with: Report Dag cache metrics under each component's own namespace #71815, Make the scheduler Dag cache size and TTL configurable #71816

[api] dag_cache_size = 0 reads as "no size limit", but it selected a mapping that never evicted and silently ignored [api] dag_cache_ttl. Age-based eviction could only be enabled by also accepting a size cap.

A TTL now applies with or without a size limit; only setting both options to 0 disables eviction. Deployments on dag_cache_size = 0 start evicting on the default hour-long TTL — set dag_cache_ttl = 0 to keep the old behaviour.

Also corrects the documented version_added for both options: 3.2.2, not 3.3.0.

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

uranusjr · 2026-08-19T08:54:39Z

We should probably add a news fragment to the behavioral change when dag_cache_size = 0 since it’s visible to the user. The change is justified as a bug fix, but the fix may in turn cause issues in existing deployments.

uranusjr

A few nits.

`[api] dag_cache_size = 0` reads as "no size limit", but it selected a mapping that never evicted at all and silently ignored `[api] dag_cache_ttl`. Age-based eviction could therefore only be enabled by also accepting a size cap, which is backwards for a deployment that wants to bound staleness rather than count. A TTL now applies with or without a size limit, and only setting both options to 0 disables eviction. Deployments on `dag_cache_size = 0` start evicting on the default hour-long TTL; setting `dag_cache_ttl = 0` restores the old behaviour. The options were also documented as added in 3.3.0. They shipped in 3.2.2.

Negative cache configuration should fail fast, and operator guidance must reflect that TTL refreshes happen only at revalidation boundaries.

Copilot

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

Validating at the shared boundary prevents non-API callers from silently clamping invalid cache settings.

Context-specific errors help operators identify invalid API settings, while defensive constructor checks protect other callers and documentation remains compatible with the spellchecker.

jason810496

We should probably add a news fragment to the behavioral change when dag_cache_size = 0 since it’s visible to the user. The change is justified as a bug fix, but the fix may in turn cause issues in existing deployments.

Thanks TP for the review. I’ve resolved all the comments, and it makes sense to add the new fragment.

…set (#71814) (#71845) * Honor the API server Dag cache TTL when no size limit is set `[api] dag_cache_size = 0` reads as "no size limit", but it selected a mapping that never evicted at all and silently ignored `[api] dag_cache_ttl`. Age-based eviction could therefore only be enabled by also accepting a size cap, which is backwards for a deployment that wants to bound staleness rather than count. A TTL now applies with or without a size limit, and only setting both options to 0 disables eviction. Deployments on `dag_cache_size = 0` start evicting on the default hour-long TTL; setting `dag_cache_ttl = 0` restores the old behaviour. The options were also documented as added in 3.3.0. They shipped in 3.2.2. * Reject negative API Dag cache values and clarify TTL behavior Negative cache configuration should fail fast, and operator guidance must reflect that TTL refreshes happen only at revalidation boundaries. * Reject negative cache values for every DBDagBag caller Validating at the shared boundary prevents non-API callers from silently clamping invalid cache settings. * Clarify cache validation context and docs wording Context-specific errors help operators identify invalid API settings, while defensive constructor checks protect other callers and documentation remains compatible with the spellchecker. * Clarify API cache TTL documentation layout (cherry picked from commit f63d321)

jason810496 · 2026-08-19T05:54:41Z

stacked with: Report Dag cache metrics under each component's own namespace #71815, Make the scheduler Dag cache size and TTL configurable #71816

[api] dag_cache_size = 0 reads as "no size limit", but it selected a mapping that never evicted and silently ignored [api] dag_cache_ttl. Age-based eviction could only be enabled by also accepting a size cap.

A TTL now applies with or without a size limit; only setting both options to 0 disables eviction. Deployments on dag_cache_size = 0 start evicting on the default hour-long TTL — set dag_cache_ttl = 0 to keep the old behaviour.

Also corrects the documented version_added for both options: 3.2.2, not 3.3.0.

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

uranusjr · 2026-08-19T08:54:39Z

We should probably add a news fragment to the behavioral change when dag_cache_size = 0 since it’s visible to the user. The change is justified as a bug fix, but the fix may in turn cause issues in existing deployments.

uranusjr

A few nits.

`[api] dag_cache_size = 0` reads as "no size limit", but it selected a mapping that never evicted at all and silently ignored `[api] dag_cache_ttl`. Age-based eviction could therefore only be enabled by also accepting a size cap, which is backwards for a deployment that wants to bound staleness rather than count. A TTL now applies with or without a size limit, and only setting both options to 0 disables eviction. Deployments on `dag_cache_size = 0` start evicting on the default hour-long TTL; setting `dag_cache_ttl = 0` restores the old behaviour. The options were also documented as added in 3.3.0. They shipped in 3.2.2.

Negative cache configuration should fail fast, and operator guidance must reflect that TTL refreshes happen only at revalidation boundaries.

Copilot

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

Validating at the shared boundary prevents non-API callers from silently clamping invalid cache settings.

Context-specific errors help operators identify invalid API settings, while defensive constructor checks protect other callers and documentation remains compatible with the spellchecker.

jason810496

We should probably add a news fragment to the behavioral change when dag_cache_size = 0 since it’s visible to the user. The change is justified as a bug fix, but the fix may in turn cause issues in existing deployments.

Thanks TP for the review. I’ve resolved all the comments, and it makes sense to add the new fragment.

…set (#71814) (#71845) * Honor the API server Dag cache TTL when no size limit is set `[api] dag_cache_size = 0` reads as "no size limit", but it selected a mapping that never evicted at all and silently ignored `[api] dag_cache_ttl`. Age-based eviction could therefore only be enabled by also accepting a size cap, which is backwards for a deployment that wants to bound staleness rather than count. A TTL now applies with or without a size limit, and only setting both options to 0 disables eviction. Deployments on `dag_cache_size = 0` start evicting on the default hour-long TTL; setting `dag_cache_ttl = 0` restores the old behaviour. The options were also documented as added in 3.3.0. They shipped in 3.2.2. * Reject negative API Dag cache values and clarify TTL behavior Negative cache configuration should fail fast, and operator guidance must reflect that TTL refreshes happen only at revalidation boundaries. * Reject negative cache values for every DBDagBag caller Validating at the shared boundary prevents non-API callers from silently clamping invalid cache settings. * Clarify cache validation context and docs wording Context-specific errors help operators identify invalid API settings, while defensive constructor checks protect other callers and documentation remains compatible with the spellchecker. * Clarify API cache TTL documentation layout (cherry picked from commit f63d321)

jason810496 · 2026-08-19T05:54:41Z

stacked with: Report Dag cache metrics under each component's own namespace #71815, Make the scheduler Dag cache size and TTL configurable #71816

[api] dag_cache_size = 0 reads as "no size limit", but it selected a mapping that never evicted and silently ignored [api] dag_cache_ttl. Age-based eviction could only be enabled by also accepting a size cap.

A TTL now applies with or without a size limit; only setting both options to 0 disables eviction. Deployments on dag_cache_size = 0 start evicting on the default hour-long TTL — set dag_cache_ttl = 0 to keep the old behaviour.

Also corrects the documented version_added for both options: 3.2.2, not 3.3.0.

Was generative AI tooling used to co-author this PR?

Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

uranusjr · 2026-08-19T08:54:39Z

We should probably add a news fragment to the behavioral change when dag_cache_size = 0 since it’s visible to the user. The change is justified as a bug fix, but the fix may in turn cause issues in existing deployments.

uranusjr

A few nits.

`[api] dag_cache_size = 0` reads as "no size limit", but it selected a mapping that never evicted at all and silently ignored `[api] dag_cache_ttl`. Age-based eviction could therefore only be enabled by also accepting a size cap, which is backwards for a deployment that wants to bound staleness rather than count. A TTL now applies with or without a size limit, and only setting both options to 0 disables eviction. Deployments on `dag_cache_size = 0` start evicting on the default hour-long TTL; setting `dag_cache_ttl = 0` restores the old behaviour. The options were also documented as added in 3.3.0. They shipped in 3.2.2.

Negative cache configuration should fail fast, and operator guidance must reflect that TTL refreshes happen only at revalidation boundaries.

Copilot

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

Validating at the shared boundary prevents non-API callers from silently clamping invalid cache settings.

Context-specific errors help operators identify invalid API settings, while defensive constructor checks protect other callers and documentation remains compatible with the spellchecker.

jason810496

We should probably add a news fragment to the behavioral change when dag_cache_size = 0 since it’s visible to the user. The change is justified as a bug fix, but the fix may in turn cause issues in existing deployments.

Thanks TP for the review. I’ve resolved all the comments, and it makes sense to add the new fragment.

…set (#71814) (#71845) * Honor the API server Dag cache TTL when no size limit is set `[api] dag_cache_size = 0` reads as "no size limit", but it selected a mapping that never evicted at all and silently ignored `[api] dag_cache_ttl`. Age-based eviction could therefore only be enabled by also accepting a size cap, which is backwards for a deployment that wants to bound staleness rather than count. A TTL now applies with or without a size limit, and only setting both options to 0 disables eviction. Deployments on `dag_cache_size = 0` start evicting on the default hour-long TTL; setting `dag_cache_ttl = 0` restores the old behaviour. The options were also documented as added in 3.3.0. They shipped in 3.2.2. * Reject negative API Dag cache values and clarify TTL behavior Negative cache configuration should fail fast, and operator guidance must reflect that TTL refreshes happen only at revalidation boundaries. * Reject negative cache values for every DBDagBag caller Validating at the shared boundary prevents non-API callers from silently clamping invalid cache settings. * Clarify cache validation context and docs wording Context-specific errors help operators identify invalid API settings, while defensive constructor checks protect other callers and documentation remains compatible with the spellchecker. * Clarify API cache TTL documentation layout (cherry picked from commit f63d321)

boring-cyborgBot added area:API Airflow's REST/HTTP API area:ConfigTemplates area:Scheduler including HA (high availability) scheduler kind:documentation labels Aug 19, 2026

jason810496 added this to the Airflow 3.3.2 milestone Aug 19, 2026

jason810496 force-pushed the fix/api-dag-cache-ttl-ignored branch from 5f87d43 to a28d57eCompare August 19, 2026 07:25

jason810496 marked this pull request as ready for review August 19, 2026 07:33

jason810496 requested review from XD-DENG, ashb, bugraoz93, choo121600, ephraimbuddy, henry3260, pierrejeambrun, rawwar and shubhamraj-git as code owners August 19, 2026 07:33

jason810496 self-assigned this Aug 19, 2026

jason810496 requested a review from uranusjr August 19, 2026 07:34

uranusjr reviewed Aug 19, 2026
View reviewed changes

Comment threadairflow-core/docs/administration-and-deployment/web-stack.rst Outdated

uranusjr reviewed Aug 19, 2026
View reviewed changes

Comment threadairflow-core/src/airflow/models/dagbag.py Outdated

uranusjr approved these changes Aug 19, 2026
View reviewed changes

jason810496 marked this pull request as draft August 19, 2026 09:03

jason810496 added 2 commits August 19, 2026 09:47

Reject negative API Dag cache values and clarify TTL behavior
5f6c258
Negative cache configuration should fail fast, and operator guidance must reflect that TTL refreshes happen only at revalidation boundaries.

jason810496 force-pushed the fix/api-dag-cache-ttl-ignored branch from a28d57e to 5f6c258Compare August 19, 2026 09:47

jason810496 requested a lite review from Copilot August 19, 2026 09:48

CopilotAI reviewed Aug 19, 2026

jason810496 added 3 commits August 19, 2026 09:55

Reject negative cache values for every DBDagBag caller
00ea7fe
Validating at the shared boundary prevents non-API callers from silently clamping invalid cache settings.

Clarify cache validation context and docs wording
b483b79
Context-specific errors help operators identify invalid API settings, while defensive constructor checks protect other callers and documentation remains compatible with the spellchecker.

Clarify API cache TTL documentation layout
a21020f

jason810496 marked this pull request as ready for review August 19, 2026 12:59

jason810496 commented Aug 19, 2026
View reviewed changes

Comment threadairflow-core/docs/administration-and-deployment/web-stack.rst Outdated
Comment threadairflow-core/src/airflow/models/dagbag.py Outdated

jason810496 merged commit f63d321 into apache:mainAug 19, 2026
140 of 159 checks passed