agent loop detected: airflow sensor poke loop never ends, task stuck

TL;DR

The sensor has not fired because its condition never became true, and the agent watching it is in a loop of its own: waiting for a task that will not complete on its own. Check the sensor's poke history to see what it is waiting on, verify whether the condition can ever become true, and either fix the upstream or fail the wait deliberately. Waiting on an impossible condition is the loop.

agent loop detected: airflow sensor poke loop never ends, task stuck

Use this when

• An agent watches an Airflow sensor task that never completes.
• The sensor keeps poking with no success.
• The agent's own wait has no end condition.

Not for this skill when

• The sensor fires normally. That is a working sensor.
• The agent polls the API in a tight loop. Fix the agent's polling, not the sensor.

Steps

1. Read the sensor task's poke history: what it checks and the recent results. Note the condition. Verify: the wait is understood
2. Verify whether the sensed thing can still arrive: the file, the partition, the record. Note the verdict. Verify: possible versus impossible is decided
3. If impossible, stop waiting: mark the dependency failed or escalate. Note the decision. Verify: an impossible wait becomes an explicit outcome
4. If possible but late, set a bounded wait with a deadline. Note the deadline. Verify: waiting is bounded
5. Record the loop: sensor, condition, and resolution. Note the record. Verify: the pattern is visible next time

Variant phrasings

agent waiting on airflow sensor forever

The symptom phrasing.

airflow sensor never fires agent

The agent-shaped search.

Compatibility: Airflow 2.x sensor task logs and the REST API for task state. Loop-breaking is agent behavior.

Why it happens

Sensors and agents both wait, which creates a nested loop: the sensor pokes the world, the agent polls the sensor. When the sensed condition is impossible, the inner loop never ends and the outer loop inherits that. The agent's bug is not the waiting; it is the missing impossibility check. Verifying that the condition can still become true is cheap and breaks the nesting: impossible conditions get explicit failures, possible ones get bounded waits.

Edge cases / pitfalls

• A sensor with no timeout waits forever by configuration. The agent cannot fix that; it can only bound its own wait.
• Failing the wait deliberately needs authority. Agents without it must escalate, not silently mark failed.
• The sensed thing arriving after the agent gave up creates a false alarm. Coordinate the give-up with the sensor's own timeout.
• Poke history with errors (not just misses) means the sensor itself is broken. Fix the sensor, not the wait.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_DSFpa1QLIhuNs04IuIKhog