Skip to content

HttpSensor deferrable mode ignores response_error_codes_allowlist #69903

Description

@Tomeshwari-02

What happened and how to reproduce it?

HttpSensor supports response_error_codes_allowlist so users can treat selected HTTP errors as "keep poking" instead of failing the task. In the synchronous path this is honored by checking self.response_error_codes_allowlist in HttpSensor.poke().

However, in deferrable mode the behavior appears to diverge after the task is deferred:

  • providers/http/src/airflow/providers/http/sensors/http.py stores the configured allowlist and uses it in poke().
  • HttpSensor.execute() creates an HttpSensorTrigger, but does not pass response_error_codes_allowlist to the trigger.
  • providers/http/src/airflow/providers/http/triggers/http.py has HttpSensorTrigger.run() retry only when the exception string starts with "404".

A DAG using something like this can behave differently depending on whether deferrable mode is enabled:

HttpSensor(
    task_id="wait_for_api",
    endpoint="/health",
    http_conn_id="my_api",
    response_error_codes_allowlist=["404", "503"],
    deferrable=True,
)

Expected behavior: 503 should be treated the same way as in non-deferrable mode, i.e. the sensor should keep waiting according to poke_interval.

Current behavior: the initial worker-side poke() can honor 503, but after deferral the trigger only handles 404. For other allowlisted statuses such as 503, the trigger does not sleep via the allowlist path and does not preserve the documented sensor behavior.

What you think should happen instead?

HttpSensorTrigger should accept and serialize the configured response_error_codes_allowlist, and HttpSensor.execute() should pass the value when creating the trigger.

The trigger should use that allowlist instead of hard-coding 404, so deferrable and non-deferrable HttpSensor behavior are consistent.

A unit test should cover a deferrable HttpSensor with a custom allowlist such as ["404", "503"].

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions