Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect try_number when searching task instances #34309

Closed
1 of 2 tasks
zachliu opened this issue Sep 12, 2023 · 2 comments · Fixed by #34635
Closed
1 of 2 tasks

Incorrect try_number when searching task instances #34309

zachliu opened this issue Sep 12, 2023 · 2 comments · Fixed by #34635
Assignees
Labels
affected_version:2.7 Issues Reported for 2.7 area:core good first issue kind:bug This is a clearly a bug

Comments

@zachliu
Copy link
Contributor

zachliu commented Sep 12, 2023

Apache Airflow version

2.7.1

What happened

In Browse -> Task Instances search, the Try Number filter is actually the "next_try_number" instead of "try_number".

2023-09-12_09-49

Task Instance Details:

2023-09-12_09-48

2023-09-12_09-48_1

I just saw this in 2.6.3 and also 2.7.1, but I don't remember the behavior in older versions

What you think should happen instead

The Try Number filter should filter on the "try_number" instead of the "next_try_number"

How to reproduce

  1. Go to the main UI -> Browse -> Task Instances search
  2. Use the Try Number filter to initial a search
  3. Go to the "Task Instance Details", find "try_number" and "next_try_number"
  4. compare them with the search results

Operating System

Debian GNU/Linux 10 (buster)

Versions of Apache Airflow Providers

No response

Deployment

Other Docker-based deployment

Deployment details

No response

Anything else

No response

Are you willing to submit PR?

  • Yes I am willing to submit a PR!

Code of Conduct

@zachliu zachliu added area:core kind:bug This is a clearly a bug needs-triage label for new issues that we didn't triage yet labels Sep 12, 2023
@SamWheating
Copy link
Contributor

I think that this is because of how try_number is defined in task_instance, it will be increased by 1 if the task is completed.

@hybrid_property
def try_number(self):
"""
Return the try number that this task number will be when it is actually run.
If the TaskInstance is currently running, this will match the column in the
database, in all other cases this will be incremented.
"""
# This is designed so that task logs end up in the right file.
if self.state == TaskInstanceState.RUNNING:
return self._try_number
return self._try_number + 1

So we should probably use prev_attempted_tries (which is the actual try number) when surfacing this in the UI. Feel free to assign to me and I can figure something out.

@potiuk
Copy link
Member

potiuk commented Sep 12, 2023

Yeah. It's beaten us more than once that try_num definition changes depends on state and in-memory/db state.

@potiuk potiuk removed the needs-triage label for new issues that we didn't triage yet label Sep 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
affected_version:2.7 Issues Reported for 2.7 area:core good first issue kind:bug This is a clearly a bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants