fix: Enable real-time extra links updates for TriggerDagRunOperator

[subhash-0000]

Fixes #58928

The "Triggered DAG" button from TriggerDagRunOperator now appears in real-time without requiring a manual page refresh.

Problem

Previously, extra links (including the "Triggered DAG" button) only appeared after:

1. The parent task completed
2. User manually refreshed the browser page

This reduced the utility of extra links, especially for monitoring triggered child DAGs in real-time.

Solution

• Add smart polling to ExtraLinks component using the existing useAutoRefresh hook
• Poll automatically when DAG is active and links are not yet available
• Stop polling once extra links appear to reduce server load
• Respects global auto_refresh_interval config and DAG paused state

Changes Made

• Modified airflow-core/src/airflow/ui/src/pages/TaskInstance/ExtraLinks.tsx
• Added refetchInterval logic with conditional polling
• Follows the same pattern used in Details.tsx for polling task instances
• No breaking changes, no new dependencies

Testing

Code Quality:

• TypeScript types are correct
• Build succeeds without errors (vite build passes)
• Follows existing patterns (useAutoRefresh hook)
• No new dependencies added
• Clear inline comments explain the logic

Manual Testing Checklist (for reviewers):

• Start Breeze with breeze start-airflow --dev-mode
• Create DAG with TriggerDagRunOperator
• Trigger the parent DAG
• Verify "Triggered DAG" button appears immediately (no refresh needed)
• Verify button remains visible while child DAG runs
• Verify polling stops once button appears (check Network tab in DevTools)
• Verify respects DAG paused state

Performance Impact

✅ Positive: Polling stops when links appear, actually reducing server load compared to continuous polling
✅ Respects auto_refresh_interval config (user-configurable)
✅ Only polls when DAG is active (not paused)

Related

This fix uses the same auto-refresh pattern already established in Details.tsx for task instance polling, ensuring consistency and maintainability across the codebase.

---

Type: Bug Fix
Component: UI (React)
Breaking Changes: None
New Dependencies: None

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[subhash-0000]

@bbovenzi
Thank you for the feedback! You're absolutely right - the previous implementation would poll forever for tasks without extra links.

I've addressed both suggestions:

1. Added useTaskServiceGetTask check to verify task.extra_links.length > 0 before polling
2. Updated Details.tsx to conditionally render the <ExtraLinks /> component only when taskInstance.extra_links.length > 0

This prevents:

• Infinite polling on tasks without extra links (e.g., PythonOperator)
• Unnecessary component rendering
• Redundant API calls

The component now only renders and polls when appropriate. Thanks for the thorough review!

[pierrejeambrun]

An easy way is to re-use the same parent refetchInterval: (query) => (isStatePending(query.state.data?.state) ? refetchInterval : false),

That is based on the 'try' 'pending' status. You can give that to the child component so it will refresh as long as the try isn't settled. Which might save you one 'useTaskServiceGetTask` call as well.

[subhash-0000]

@pierrejeambrun Thank you for the feedback! I've implemented both of your suggestions:

Reused parent's refetchInterval pattern

As you suggested, I'm now passing the same refetch logic to child components based on the try instance's pending state. Both ExtraLinks and BlockingDeps receive isStatePending(tryInstance?.state) ? refetchInterval : false as a prop. This eliminated the useTaskServiceGetTask call from ExtraLinks and removed duplicate useAutoRefresh hooks. Polling now automatically stops when the try instance is no longer pending.

Fixed invalid property access

Removed the conditional check for taskInstance?.extra_links - you're absolutely right that this property doesn't exist on TaskInstanceResponse. The ExtraLinks component now renders unconditionally and handles its own empty state internally.

The architecture is much cleaner now with a single source of truth for refresh logic in the parent component. I also applied the same pattern to BlockingDeps for consistency so it benefits from the same polling behavior. Ready for another review!

[boring-cyborg]

Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions.

[github-actions]

Backport successfully created: v3-1-test

Status	Branch	Result
✅	v3-1-test