[v3-3-test] Fix retry policy overrides not persisted to task instance history (#69235)#69241
Merged
Merged
Conversation
… history (#69235) AIP-105's per-try audit trail (retry_delay_override, retry_reason) is meant to live durably in task_instance_history — the columns on the live task_instance row are transient and cleared when the task next enters RUNNING. The Execution API retry handler wrote the overrides only into the live-row UPDATE and archived the task instance to history before those values were applied, so the history columns were always NULL. That silently dropped the audit trail the feature advertises, while retry timing (which reads the live row) stayed correct. Setting the overrides on the task instance before prepare_db_for_next_try() lets record_ti() snapshot them into task_instance_history, restoring the per-try record. (cherry picked from commit 3bfa5ff) Co-authored-by: Rahul Vats <43964496+vatsrahul1001@users.noreply.github.com>
1 task
vatsrahul1001
approved these changes
Jul 2, 2026
amoghrajesh
approved these changes
Jul 2, 2026
Lee-W
approved these changes
Jul 2, 2026
vatsrahul1001
added a commit
that referenced
this pull request
Jul 3, 2026
… history (#69235) (#69241) AIP-105's per-try audit trail (retry_delay_override, retry_reason) is meant to live durably in task_instance_history — the columns on the live task_instance row are transient and cleared when the task next enters RUNNING. The Execution API retry handler wrote the overrides only into the live-row UPDATE and archived the task instance to history before those values were applied, so the history columns were always NULL. That silently dropped the audit trail the feature advertises, while retry timing (which reads the live row) stayed correct. Setting the overrides on the task instance before prepare_db_for_next_try() lets record_ti() snapshot them into task_instance_history, restoring the per-try record. (cherry picked from commit 3bfa5ff) Co-authored-by: Rahul Vats <43964496+vatsrahul1001@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
AIP-105's per-try audit trail (retry_delay_override, retry_reason) is meant to
live durably in task_instance_history — the columns on the live task_instance
row are transient and cleared when the task next enters RUNNING. The Execution
API retry handler wrote the overrides only into the live-row UPDATE and archived
the task instance to history before those values were applied, so the history
columns were always NULL. That silently dropped the audit trail the feature
advertises, while retry timing (which reads the live row) stayed correct.
Setting the overrides on the task instance before prepare_db_for_next_try() lets
record_ti() snapshot them into task_instance_history, restoring the per-try
record.
(cherry picked from commit 3bfa5ff)
Co-authored-by: Rahul Vats 43964496+vatsrahul1001@users.noreply.github.com