Description
The ExtraLinks component in the task instance detail view does not forward the currently selected try_number to the extra links API endpoint. As a result, BaseOperatorLink.get_link always receives a ti_key with the latest attempt's try_number, making it impossible to return attempt-specific URLs.
The Details page already tracks the selected attempt via SearchParamsKeys.TRY_NUMBER and uses it to fetch per-attempt data via useTaskInstanceServiceGetTaskInstanceTryDetails. However, ExtraLinks does not receive or forward this value.
Call chain today:
- UI calls
GET /dags/{dag_id}/dagRuns/{run_id}/taskInstances/{task_id}/links — no try_number param
- Endpoint fetches
TaskInstance row (always reflects latest attempt)
- Calls
task.get_extra_links(ti, link_name) → link.get_link(self, ti_key=ti.key)
ti.key builds TaskInstanceKey(..., self.try_number, ...) — always the latest
Use case/motivation
A custom BaseOperatorLink plugin that links to an external log viewer filtered by worker hostname and execution time window. When a task retries across different workers, each attempt runs on a different host. The link should point to the correct host's logs for the attempt the user is viewing — not always the latest attempt. The plugin can query TaskInstanceHistory using ti_key.try_number to resolve per-attempt metadata, but only if try_number correctly reflects the viewed attempt.
Suggested change:
- Add optional
try_number query parameter to the extra links endpoint
- Pass
tryNumber from Details.tsx to ExtraLinks, which forwards it to the API call
- In the endpoint, when
try_number is provided, use ti.key.with_try_number(try_number) so get_link receives the viewed attempt's try_number
No changes to BaseOperatorLink.get_link signature needed — TaskInstanceKey already has try_number.
Related issues
None found.
Are you willing to submit a PR?
Code of Conduct
Airflow version: 3.2.0
Description
The
ExtraLinkscomponent in the task instance detail view does not forward the currently selectedtry_numberto the extra links API endpoint. As a result,BaseOperatorLink.get_linkalways receives ati_keywith the latest attempt'stry_number, making it impossible to return attempt-specific URLs.The Details page already tracks the selected attempt via
SearchParamsKeys.TRY_NUMBERand uses it to fetch per-attempt data viauseTaskInstanceServiceGetTaskInstanceTryDetails. However,ExtraLinksdoes not receive or forward this value.Call chain today:
GET /dags/{dag_id}/dagRuns/{run_id}/taskInstances/{task_id}/links— notry_numberparamTaskInstancerow (always reflects latest attempt)task.get_extra_links(ti, link_name)→link.get_link(self, ti_key=ti.key)ti.keybuildsTaskInstanceKey(..., self.try_number, ...)— always the latestUse case/motivation
A custom
BaseOperatorLinkplugin that links to an external log viewer filtered by worker hostname and execution time window. When a task retries across different workers, each attempt runs on a different host. The link should point to the correct host's logs for the attempt the user is viewing — not always the latest attempt. The plugin can queryTaskInstanceHistoryusingti_key.try_numberto resolve per-attempt metadata, but only iftry_numbercorrectly reflects the viewed attempt.Suggested change:
try_numberquery parameter to the extra links endpointtryNumberfromDetails.tsxtoExtraLinks, which forwards it to the API calltry_numberis provided, useti.key.with_try_number(try_number)soget_linkreceives the viewed attempt'stry_numberNo changes to
BaseOperatorLink.get_linksignature needed —TaskInstanceKeyalready hastry_number.Related issues
None found.
Are you willing to submit a PR?
Code of Conduct
Airflow version: 3.2.0