Skip to content

Pass try_number to extra links API so BaseOperatorLink.get_link can return per-attempt URLs #65354

@khoaanguyenn

Description

@khoaanguyenn

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:

  1. UI calls GET /dags/{dag_id}/dagRuns/{run_id}/taskInstances/{task_id}/links — no try_number param
  2. Endpoint fetches TaskInstance row (always reflects latest attempt)
  3. Calls task.get_extra_links(ti, link_name)link.get_link(self, ti_key=ti.key)
  4. 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:

  1. Add optional try_number query parameter to the extra links endpoint
  2. Pass tryNumber from Details.tsx to ExtraLinks, which forwards it to the API call
  3. 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?

  • Yes I am willing to submit a PR!

Code of Conduct

Airflow version: 3.2.0

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:APIAirflow's REST/HTTP APIarea:UIRelated to UI/UX. For Frontend Developers.kind:featureFeature Requests

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions