Incorrect try_number when searching task instances

[zachliu]

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".

Task Instance Details:

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

• I agree to follow this project's Code of Conduct

[SamWheating]

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.

airflow/airflow/models/taskinstance.py

Lines 607 to 618 in eed2901

	@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]

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