The GitHub Actions job "Tests (AMD)" on airflow.git/triggerer-via-execution-api has failed. Run started by GitHub user kaxil (triggered by kaxil).
Head commit for run: 0928221d1058f72a8541957185dc71a762b68031 / Kaxil Naik <[email protected]> Run the Airflow triggerer through the Execution API (AIP-92) The triggerer supervisor now orchestrates entirely through the Execution API and holds no metadata-database connection. It registers and heartbeats a liveness Job, claims triggers, fetches their RunTrigger workloads, and reports events, failures, and cleanup over HTTP; the api-server is the only process that touches the database. The supervisor already served the runtime requests its triggers make (connections, variables, XComs) through the Execution API, but in-process against the database; this points that client at the api-server and moves orchestration onto it too. The supervisor's database-direct orchestration is removed rather than overridden, so the supervisor holds no database code at all and no database-backed runtime fallback remains. The command runs the job runner directly instead of through run_job (whose prepare_for_execution would write a Job row at startup) and skips the startup database checks. Transient API errors re-queue and retry rather than tearing down running triggers; a non-transient 4xx surfaces loudly instead of looping silently. The SDK client returns trigger workloads as raw dicts (it must not import the core RunTrigger type); the supervisor validates them. Trigger logs stay retrievable: the supervisor registers a per-trigger logging factory for each fetched workload, keys the log filename on the registered Job id, and records the triggerer's own hostname. Report URL: https://github.com/apache/airflow/actions/runs/26907196361 With regards, GitHub Actions via GitBox --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
