apache/airflow

ExternalTaskSensor: An option to use the data_interval variables rather than execution_date

Open

#26.429 geöffnet am 16. Sept. 2022

Auf GitHub ansehen
 (5 Kommentare) (1 Reaktion) (0 zugewiesene Personen)Python (16.781 Forks)batch import
good first issuekind:feature

Repository-Metriken

Stars
 (44.809 Stars)
PR-Merge-Metriken
 (Durchschn. Merge 7T 18h) (834 gemergte PRs in 30 T)

Beschreibung

Description

Since execution_date is deprecated, it makes sense that this sensor or a new version of it (for backward compatibility) uses the data_interval variables.

Use case/motivation

I want to make sure that the data interval this DAG is about to operate on is covered by another DAG. For example, data was loaded up to this DAG's data_interval_end.

I believe the sensor itself is simple to write. It just uses data_interval_end rather than execution_date and it doesn't look for one specific task, any external.data_interval_end > self.data_interval_end is acceptable.

This is the equivalent of ExternalTaskSensor with execution_delta set to self.interval_start - closest_external_interval.interval_start which can be calculated manually but will fail later if the external DAG schedule is changed.

Related issues

No response

Are you willing to submit a PR?

  • Yes I am willing to submit a PR!

Code of Conduct

Contributor Guide

Research-Richtung
Untersuchen Sie die aktuelle Implementierung von ExternalTaskSensor in airflow/sensors/external task sensor.py. Verstehen Sie, wie execution date derzeit verwendet wird, um die externe Aufgabe zu finden. Untersuchen Sie, wie Datenintervallvariablen (data interval start, data interval end) in Aufgabeninstanzen verfügbar sind. Schlagen Sie einen neuen Parameter (z. B. use data interval) oder eine neue Sensor Klasse vor, die data interval end anstelle von execution date vergleicht. Überprüfen Sie die Kommentare im Issue auf zusätzliche Anforderungen oder Einschränkungen. Stellen Sie die Abwärtskompatibilität mit der bestehenden Verwendung von execution date sicher.
Tech Stack
python
Domain
backend
Issue Type
Funktion
SchwierigkeitGeschätzte Implementierungsschwierigkeit für neue Contributors, von 1 für sehr kleine Änderungen bis 5 für Expertenarbeit.
3
Geschätzte ZeitEin grober Zeitrahmen, um zu recherchieren, zu implementieren, zu testen und einen Pull Request vorzubereiten.
1-3 Stunden
AktivitätsstatusWie verfügbar das Issue gerade wirkt: frisch, aktiv, stale, blockiert oder wartet auf Maintainer-Input.
Aktiv
KlarheitWie klar das Issue die erwartete Änderung, Akzeptanzkriterien und den nächsten Schritt erklärt.
Meist klar
Voraussetzungen
AirflowPython
EinsteigerfreundlichkeitEin Score von 1 bis 100, der schätzt, wie zugänglich dieses Issue für First-Time Contributors ist.
65