Use XCom to correctly display the execution date from triggered DAG in TriggerDagOperator's extra link

[o-nikolas]

Mitigate #19264 such that the extra link from the triggered dag at least loads the current date and
displays all current dag runs runs. See that issue for further discussion on future DB changes.

---

^ Add meaningful description above

Read the Pull Request Guidelines for more information.
In case of fundamental code change, Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in UPDATING.md.

[o-nikolas]

@ljades @uranusjr Quick PR to remove the erroneous execution_date from the triggered url.

@uranusjr: Two of the tests are failing and I have no idea why. I can't reproduce it locally (those tests pass when I run them) and they aren't producing an exception or any logging, it just times out at 68% completion. Any ideas on how I can move forward here?

[uranusjr]

it just times out at 68% completion. Any ideas on how I can move forward here?

Don't worry about those, the CI runner timed out.

[ashb]

This fix doesn't look right to me -- by not including the execution date it will link to the latest run instead.

[ljades]

This fix doesn't look right to me -- by not including the execution date it will link to the latest run instead.

@ashb
The issue working to be mitigated here is that the execution date parameter wasn't being used properly at all anyway and was linking to a poorly filtered view of the DAG, so mitigating it at least allows the user to view the latest and filter easily to the target.

[o-nikolas]

This fix doesn't look right to me -- by not including the execution date it will link to the latest run instead.

@ashb The issue working to be mitigated here is that the execution date parameter wasn't being used properly at all anyway and was linking to a poorly filtered view of the DAG, so mitigating it at least allows the user to view the latest and filter easily to the target.

Hey @ashb,
@ljades summarized it correctly. I know the original issue is quite long, but if you read that, it that will provide a lot of context so that this makes sense. Specifically the latest comment here. This PR basically does 1) from that comment.

Basically a "real fix" is quite tricky and I wasn't getting much feedback in the ticket, so as a stop gap this PR will at least remove the filter so that you see all runs from current run back which seemed like a decent default for the time being.

[ashb]

From that issue:

So the webserver does not have access to the results of those computations when it's building the link

Store the triggered execution date in XCom and pull it in the operator link, like

airflow/airflow/providers/google/cloud/operators/bigquery.py

Line 737 in 7622f5e

context['task_instance'].xcom_push(key='job_id', value=job_id)

and use it like

airflow/airflow/providers/google/cloud/operators/bigquery.py

Lines 63 to 69 in 7622f5e

	job_id = XCom.get_one(
	dag_id=operator.dag.dag_id,
	task_id=operator.task_id,
	execution_date=dttm,
	key='job_id',
	)
	return BIGQUERY_JOB_DETAILS_LINK_FMT.format(job_id=job_id) if job_id else ''

[ashb]

Store date/runid (both please) in XCom and use to build the link.

[o-nikolas]

Store date/runid (both please) in XCom and use to build the link.

Thanks for the feedback Ash! I'll play around with this and get back to this PR soon 👍

[o-nikolas]

Hey @ashb, do you have a minute to take another look at this PR? Appreciate it!

[o-nikolas]

Hey @ashb your requested changes should be in. Do you have time to have a quick review of this one?

[ashb]

Sorry. LGTM!