You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by "CreeperBeatz (via GitHub)" <gi...@apache.org> on 2025/12/22 08:47:06 UTC
[I] Using --celery-hostname causes workers to reserve, but never execute tasks [airflow]
CreeperBeatz opened a new issue, #59707:
URL: https://github.com/apache/airflow/issues/59707
### Apache Airflow Provider(s)
celery
### Versions of Apache Airflow Providers
3.14.1
### Apache Airflow version
3.1.5
### Operating System
WSL Ubuntu 22.04
### Deployment
Virtualenv installation
### Deployment details
Installed with UV:
```
uv pip install "apache-airflow[celery]==3.1.5" --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-3.1.5/constraints-3.12.txt"
```
### What happened
When starting a Celery worker with a custom --celery-hostname, the worker successfully connects to the broker and reserves tasks, but never executes them.
The task stays in reserved state with:
acknowledged: False
worker_pid: None
time_start: None
Removing --celery-hostname and using the default hostname makes everything work correctly.
#### Output when using `--celery-hostname`:
```
(.venv) me@DESKTOP-MAG5124:~/airflow$ celery -A airflow.providers.celery.executors.celery_executor_utils.app inspect reserved
-> default@DESKTOP-MAG5124: OK
* {'id': '923f016a-a3da-42c2-bf57-4f4193e11721', 'name': 'execute_workload', 'args': ['{"token":"eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIwMTliNDUyNi00MmY2LTdmNWQtYWQ1Zi1jNWY4MWRlMjAxNTEiLCJqdGkiOiJkOGUzZDdlODc5ZDE0OGE2YWNiZWQ5Y2ZmZmMwMjZmZSIsImF1ZCI6InVybjphaXJmbG93LmFwYWNoZS5vcmc6dGFzayIsIm5iZiI6MTc2NjM5MTY5NCwiZXhwIjoxNzY2MzkyMjk0LCJpYXQiOjE3NjYzOTE2OTR9.tGA_sdHlGhTf6UXHO8eX5a7IeJyHpVUnUKSKtXW-Lhl4J2Y9UQEg0j5az7SSSulzudcxjDqSCuXP9V2ksZyDeQ","ti":{"id":"019b4526-42f6-7f5d-ad5f-c5f81de20151","dag_version_id":"019b450d-b021-79cd-8374-49824e6cc8c5","task_id":"get_airflow_variables","dag_id":"dirbg_crawler","run_id":"manual__2025-12-22T07:57:45+00:00","try_number":2,"map_index":-1,"pool_slots":1,"queue":"default","priority_weight":2,"parent_context_carrier":{},"context_carrier":{}},"dag_rel_path":"dirbg_crawler.py","bundle_info":{"name":"dags-folder","version":null},"log_path":"dag_id=dirbg_crawler/run_id=manual__2025-12-22T07:57:45+00:00/task_id=get_airflow_variables/att
empt=2.log","type":"ExecuteTask"}'], 'kwargs': {}, 'type': 'execute_workload', 'hostname': 'default@DESKTOP-MAG5124', 'time_start': None, 'acknowledged': False, 'delivery_info': {'exchange': '', 'routing_key': 'default', 'priority': 0, 'redelivered': False}, 'worker_pid': None}
1 node online.
```
```
(.venv) me@DESKTOP-MAG5124:~/airflow$ celery -A airflow.providers.celery.executors.celery_executor_utils.app inspect active_queues
-> default@DESKTOP-MAG5124: OK
* {'name': 'default', 'exchange': {'name': 'default', 'type': 'direct', 'arguments': None, 'durable': True, 'passive': False, 'auto_delete': False, 'delivery_mode': None, 'no_declare': False}, 'routing_key': 'default', 'queue_arguments': None, 'binding_arguments': None, 'consumer_arguments': None, 'durable': True, 'exclusive': False, 'auto_delete': False, 'no_ack': False, 'alias': None, 'bindings': [], 'no_declare': None, 'expires': None, 'message_ttl': None, 'max_length': None, 'max_length_bytes': None, 'max_priority': None}
1 node online.
```
#### Output when **NOT** using `--celery-hostname`:
Note: The task is already executing.
```
(.venv) dani@DESKTOP-MAG5124:~/airflow$ celery -A airflow.providers.celery.executors.celery_executor_utils.app inspect reserved
-> celery@DESKTOP-MAG5124: OK
- empty -
```
### What you think should happen instead
Worker should execute reserved tasks regardless of custom hostname.
### How to reproduce
This does NOT work - task reserved but never executed
```
airflow celery worker \
--queues my_queue \
--concurrency 1 \
--celery-hostname "myworker@%h"
```
This is valid even if you set the --celery-hostname to "celery@%h" which should be the default option.
This WORKS
```
airflow celery worker \
--queues my_queue \
--concurrency 1
```
### Anything else
_No response_
### Are you willing to submit PR?
- [ ] Yes I am willing to submit a PR!
### Code of Conduct
- [x] I agree to follow this project's [Code of Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Using --celery-hostname causes workers to reserve, but never execute tasks [airflow]
Posted by "shivaam (via GitHub)" <gi...@apache.org>.
shivaam commented on issue #59707:
URL: https://github.com/apache/airflow/issues/59707#issuecomment-4108348088
> ## Updated Investigation Report
> ### Regression Source
> Commit `16829d7694` — "Add duplicate hostname check for Celery workers ([#58591](https://github.com/apache/airflow/pull/58591))" — landed in **celery provider 3.14.0**. This is the only CLI change between 3.13.1 and 3.14.0, consistent with reports that downgrading to 3.13.1 fixes the issue.
>
> ### Root Cause
> The duplicate hostname check calls `celery_app.control.inspect().active_queues()` **before** `celery_app.worker_main()`. The `inspect()` call opens broker connections and initializes internal connection/producer pools on the Celery app. When `worker_main()` starts the worker with the `prefork` pool (which uses `fork()`), this pre-initialized state interferes with the worker's internal communication — tasks are received from the broker but never dispatched to pool workers.
>
> I confirmed this by observing that `app.amqp._producer_pool` is non-None at `worker_main()` time when the bug occurs, and None when it works correctly. Clearing this state with `kombu.pools.reset()` after the `inspect()` call restores correct behavior.
>
> I have not fully traced the exact internal mechanism by which the pre-initialized pools break the prefork dispatch path, but the correlation is consistent across all tests.
>
> ### Fixes That Work (verified on live Airflow 3.2 + Celery 5.6.2 + Redis)
> **Option A — Remove the duplicate hostname check entirely.** Simplest fix, minor UX loss (no warning if you accidentally start two workers with the same hostname). Tested and confirmed working.
>
> **Option B — Use a temp app + `kombu.pools.reset()`:** Keeps the check, cleans up connection state before `worker_main()`:
>
> if args.celery_hostname:
> from celery import Celery as _TempCelery
> temp_app = _TempCelery(broker=celery_app.conf.broker_url)
> try:
> active_workers = temp_app.control.inspect().active_queues()
> if active_workers:
> celery_hostname = args.celery_hostname
> if any(
> name == celery_hostname or name.endswith(f"@{celery_hostname}")
> for name in active_workers
> ):
> raise SystemExit(
> f"Error: A worker with hostname '{celery_hostname}' is already running."
> )
> finally:
> temp_app.close()
> import kombu.pools
> kombu.pools.reset()
> The `kombu.pools.reset()` is essential — `kombu.pools` is a process-global registry keyed by broker URL, so even a separate temp app's connections end up in the same global pool.
>
> ### Approaches That Did Not Work
> Approach Result
> Reset `app.amqp._producer_pool = None` only Insufficient — `kombu.pools` still holds state
> Temp app without `kombu.pools.reset()` Global pools still polluted
> `app.pool.force_close_all()` Closes pool permanently, Celery can't reconnect
> Investigation branch with diagnostic scripts: [`investigate/celery-hostname-59707`](https://github.com/shivaam/airflow/tree/investigate/celery-hostname-59707)
@dheerajturaga Do you have any idea why the duplicate check might be causing this isuse?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Using --celery-hostname causes workers to reserve, but never execute tasks [airflow]
Posted by "shivaam (via GitHub)" <gi...@apache.org>.
shivaam commented on issue #59707:
URL: https://github.com/apache/airflow/issues/59707#issuecomment-4108310186
## Investigation Report
I spent time investigating this end-to-end on a live Airflow 3.2 instance (CeleryExecutor, Redis broker, PostgreSQL backend, Celery 5.6.2). Here's what I found.
### Regression Source
The bug was introduced by commit `16829d7694` — "Add duplicate hostname check for Celery workers (#58591)" — which landed in **celery provider 3.14.0**. This is confirmed by:
- `git log --oneline providers-celery/3.13.1..providers-celery/3.14.0 -- providers/celery/src/airflow/providers/celery/cli/celery_command.py` showing it as the **only** CLI change between those versions
- Multiple comments on this issue confirming that downgrading to 3.13.1 fixes it
### Root Cause
The duplicate hostname check (lines 222-236 of `celery_command.py`) calls `celery_app.control.inspect().active_queues()` **before** `celery_app.worker_main()`. This is the problem.
**The chain:**
1. `inspect().active_queues()` broadcasts a control message to Redis and waits for replies
2. This lazily initializes `celery_app.amqp._producer_pool` and opens TCP sockets to the Redis broker
3. These pools and sockets register in **`kombu.pools`** — a **process-global** registry keyed by broker URL
4. `worker_main()` then calls `fork()` to create prefork pool workers
5. Children inherit the parent's open socket file descriptors
6. Parent (consumer) and children (pool workers) now share the same Redis sockets
7. The `-O fair` scheduling strategy requires consumer-to-pool IPC over these connections
8. Shared sockets cause silent communication failure — tasks are received but never dispatched
**Key discovery: `kombu.pools` is global, not per-app.** Even creating a separate "temp" Celery app for the inspection pollutes the shared global pool because `kombu.pools` is keyed by broker URL, not app identity:
```
# From our diagnostic script:
A.pool is B.pool: True # Same object!
A.amqp.producer_pool is B.amqp.producer_pool: True # Same object!
```
### Live Test Results
**Environment:** Airflow 3.2.0.dev0, Celery 5.6.2, Redis 6.2.20, PostgreSQL (RDS), EC2 (Amazon Linux 2023)
| Test | Worker hostname | Result |
|------|----------------|--------|
| Baseline (no `--celery-hostname`) | `celery@ip-10-0-2-61...` | Task **succeeded** in 8.1s |
| Bug repro (with `--celery-hostname`) | `myworker@ip-10-0-2-61...` | Task **stuck in RESERVED** 60s+ (`acknowledged=False`, `worker_pid=None`) |
| Fix applied (temp app + `kombu.pools.reset()`) | `myworker@ip-10-0-2-61...` | Task **succeeded** in 2.6s |
**Bug repro logs (task stuck):**
```
Task execute_workload[5c97cd55...] received
<< NO FURTHER OUTPUT — task never dispatched to pool worker >>
celery inspect reserved:
hostname: myworker@ip-10-0-2-61.us-west-2.compute.internal
time_start: None
acknowledged: False
worker_pid: None
DB: test_celery_hostname | say_hello | queued (never progressed)
```
**Fix verified logs (task executes):**
```
[DEBUG] app.amqp._producer_pool is None (GOOD) at worker_main() time.
Task execute_workload[b41f1956...] received
[b41f1956...] Executing workload in Celery: task_id='say_hello'
Task finished exit_code=0 final_state=success
Task execute_workload[b41f1956...] succeeded in 2.596s
DB: say_hello | success
```
### The Fix
Use a temporary Celery app for the `inspect()` call, then **reset `kombu.pools`** in a `finally` block to clear any global state pollution:
```python
if args.celery_hostname:
from celery import Celery as _TempCelery
temp_app = _TempCelery(broker=celery_app.conf.broker_url)
try:
active_workers = temp_app.control.inspect().active_queues()
if active_workers:
celery_hostname = args.celery_hostname
if any(
name == celery_hostname or name.endswith(f"@{celery_hostname}")
for name in active_workers
):
raise SystemExit(
f"Error: A worker with hostname '{celery_hostname}' is already running."
)
finally:
temp_app.close()
import kombu.pools
kombu.pools.reset() # CRITICAL: clear global pool state before fork
```
The `kombu.pools.reset()` is essential — without it, even the temp app's connections persist in the global registry and get inherited after fork.
**Secondary fix:** The duplicate hostname detection also has a bug where hostnames containing `@` (e.g., `myworker@mymachine`) fail the `endswith("@myworker@mymachine")` check. Added exact-match fallback: `name == celery_hostname or name.endswith(...)`.
### Approaches We Tried and Discarded
| Approach | Why it didn't work |
|----------|-------------------|
| Convert `args.concurrency` from `int` to `str` | Correct style fix but unrelated to root cause — Celery handles int coercion |
| Reset `app.amqp._producer_pool = None` after inspect | Insufficient — `kombu.pools` still holds open sockets in the global registry |
| Temp app alone (no `kombu.pools.reset()`) | `kombu.pools` is keyed by broker URL, not app — temp app pollutes the same global entry |
| `app.pool.force_close_all()` | Closes pool permanently — Celery can't create new connections later |
| Remove `-O fair` flag | Workaround, not a fix — `-O fair` prevents task starvation in production |
| Set hostname via `celery_app.conf` instead of CLI | Doesn't address the connection pool pollution |
### How to Reproduce
```bash
# 1. Configure Airflow with CeleryExecutor + Redis broker
export AIRFLOW__CORE__EXECUTOR=CeleryExecutor
export AIRFLOW__CELERY__BROKER_URL=redis://localhost:6379/0
# 2. Start scheduler + api-server
airflow api-server &
airflow scheduler &
# 3. Start worker WITH --celery-hostname
airflow celery worker --queues default --concurrency 1 --celery-hostname "myworker@%h"
# 4. Trigger any DAG
airflow dags trigger <any_dag>
# 5. After 60s, check:
celery -A airflow.providers.celery.executors.celery_executor_utils.app inspect reserved
# → Task stuck with acknowledged=False, worker_pid=None
```
Full investigation docs and diagnostic scripts are on branch [`investigate/celery-hostname-59707`](https://github.com/shivaam/airflow/tree/investigate/celery-hostname-59707) in `.claude/celery-hostname-issue-59707/` and `dev/`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Using --celery-hostname causes workers to reserve, but never execute tasks [airflow]
Posted by "sonbaoharryson (via GitHub)" <gi...@apache.org>.
sonbaoharryson commented on issue #59707:
URL: https://github.com/apache/airflow/issues/59707#issuecomment-3780177055
thanks @brunocmacedo , i did same things you provided, worked for me!!!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Using --celery-hostname causes workers to reserve, but never execute tasks [airflow]
Posted by "mszmidt (via GitHub)" <gi...@apache.org>.
mszmidt commented on issue #59707:
URL: https://github.com/apache/airflow/issues/59707#issuecomment-4003379952
Yeah, it was a huge pain... For us it started with 3.1.3 I believe. And took ~2 weeks to find this issue and alter config. (Self-built docker images installed with pipx) In the meantime we changed everything including Dockerfiles...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Using --celery-hostname causes workers to reserve, but never execute tasks [airflow]
Posted by "shivaam (via GitHub)" <gi...@apache.org>.
shivaam commented on issue #59707:
URL: https://github.com/apache/airflow/issues/59707#issuecomment-4108337693
## Updated Investigation Report
*(Correcting my earlier comment with a more precise analysis — I overstated certainty on some points.)*
### Regression Source
Commit `16829d7694` — "Add duplicate hostname check for Celery workers (#58591)" — landed in **celery provider 3.14.0**. This is the only CLI change between 3.13.1 and 3.14.0, consistent with reports that downgrading to 3.13.1 fixes the issue.
### Root Cause
The duplicate hostname check calls `celery_app.control.inspect().active_queues()` **before** `celery_app.worker_main()`. The `inspect()` call opens broker connections and initializes internal connection/producer pools on the Celery app. When `worker_main()` starts the worker with the `prefork` pool (which uses `fork()`), this pre-initialized state interferes with the worker's internal communication — tasks are received from the broker but never dispatched to pool workers.
I confirmed this by observing that `app.amqp._producer_pool` is non-None at `worker_main()` time when the bug occurs, and None when it works correctly. Clearing this state with `kombu.pools.reset()` after the `inspect()` call restores correct behavior.
I have not fully traced the exact internal mechanism by which the pre-initialized pools break the prefork dispatch path, but the correlation is consistent across all tests.
### Fixes That Work (verified on live Airflow 3.2 + Celery 5.6.2 + Redis)
**Option A — Remove the duplicate hostname check entirely.** Simplest fix, minor UX loss (no warning if you accidentally start two workers with the same hostname). Tested and confirmed working.
**Option B — Use a temp app + `kombu.pools.reset()`:** Keeps the check, cleans up connection state before `worker_main()`:
```python
if args.celery_hostname:
from celery import Celery as _TempCelery
temp_app = _TempCelery(broker=celery_app.conf.broker_url)
try:
active_workers = temp_app.control.inspect().active_queues()
if active_workers:
celery_hostname = args.celery_hostname
if any(
name == celery_hostname or name.endswith(f"@{celery_hostname}")
for name in active_workers
):
raise SystemExit(
f"Error: A worker with hostname '{celery_hostname}' is already running."
)
finally:
temp_app.close()
import kombu.pools
kombu.pools.reset()
```
The `kombu.pools.reset()` is essential — `kombu.pools` is a process-global registry keyed by broker URL, so even a separate temp app's connections end up in the same global pool.
### Approaches That Did Not Work
| Approach | Result |
|----------|--------|
| Reset `app.amqp._producer_pool = None` only | Insufficient — `kombu.pools` still holds state |
| Temp app without `kombu.pools.reset()` | Global pools still polluted |
| `app.pool.force_close_all()` | Closes pool permanently, Celery can't reconnect |
Investigation branch with diagnostic scripts: [`investigate/celery-hostname-59707`](https://github.com/shivaam/airflow/tree/investigate/celery-hostname-59707)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Using --celery-hostname causes workers to reserve, but never execute tasks [airflow]
Posted by "CreeperBeatz (via GitHub)" <gi...@apache.org>.
CreeperBeatz commented on issue #59707:
URL: https://github.com/apache/airflow/issues/59707#issuecomment-3681114347
I just tested downgrading to Celery Providers 3.13.1, and the issue DOES NOT exist there. This is something that happened in the 3.14.* release of the celery providers.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Using --celery-hostname causes workers to reserve, but never execute tasks [airflow]
Posted by "brunocmacedo (via GitHub)" <gi...@apache.org>.
brunocmacedo commented on issue #59707:
URL: https://github.com/apache/airflow/issues/59707#issuecomment-3687397662
After a couple hours trying to find what was the issue after 3.1.5 upgrade I found this and can confirm that I have the same issue with [apache-airflow-providers-celery 3.14.1](https://pypi.org/project/apache-airflow-providers-celery/). Falling back to 3.13.1 solved the issue for now.
As a reference, here is the airflow-worker definition in my docker compose. In my case i need to set celery-hostname due to the three replicas being used.
```yaml
airflow-worker:
<<: *airflow-common
# container name is not set due to the usage of replicas
#container_name: airflow-worker
command: celery worker --celery-hostname=%h
healthcheck:
test:
- "CMD-SHELL"
- 'celery --app airflow.providers.celery.executors.celery_executor.app inspect ping -d "celery@$${HOSTNAME}" || celery --app airflow.executors.celery_executor.app inspect ping -d "celery@$${HOSTNAME}"'
interval: 30s
timeout: 10s
retries: 5
start_period: 30s
environment:
<<: *airflow-common-env
# Required to handle warm shutdown of the celery workers properly
# See https://airflow.apache.org/docs/docker-stack/entrypoint.html#signal-propagation
DUMB_INIT_SETSID: "0"
restart: always
depends_on:
<<: *airflow-common-depends-on
airflow-apiserver:
condition: service_healthy
airflow-init:
condition: service_completed_successfully
# below is not set so flower can detect the different workers
#hostname: "{{.Node.ID}}-{{.Task.Slot}}"
deploy:
replicas: 3 # Number of worker replicas to run, increase this to create multiple worker containers allowing more parallel task execution
mem_swappiness: 0 # Disable swap to prevent slowdowns
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Using --celery-hostname causes workers to reserve, but never execute tasks [airflow]
Posted by "shivaam (via GitHub)" <gi...@apache.org>.
shivaam commented on issue #59707:
URL: https://github.com/apache/airflow/issues/59707#issuecomment-4174346189
@auvipy wondering if you have any thoughts on this issue. Any inputs on what we can check further?
```
The duplicate hostname check calls celery_app.control.inspect().active_queues() before celery_app.worker_main(). The inspect() call opens broker connections and initializes internal connection/producer pools on the Celery app. When worker_main() starts the worker with the prefork pool (which uses fork()), this pre-initialized state interferes with the worker's internal communication — tasks are received from the broker but never dispatched to pool workers.
I confirmed this by observing that app.amqp._producer_pool is non-None at worker_main() time when the bug occurs, and None when it works correctly. Clearing this state with kombu.pools.reset() after the inspect() call restores correct behavior.
I have not fully traced the exact internal mechanism by which the pre-initialized pools break the prefork dispatch path, but the correlation is consistent across all tests.
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Using --celery-hostname causes workers to reserve, but never execute tasks [airflow]
Posted by "dheerajturaga (via GitHub)" <gi...@apache.org>.
dheerajturaga closed issue #59707: Using --celery-hostname causes workers to reserve, but never execute tasks
URL: https://github.com/apache/airflow/issues/59707
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Using --celery-hostname causes workers to reserve, but never execute tasks [airflow]
Posted by "mxmua (via GitHub)" <gi...@apache.org>.
mxmua commented on issue #59707:
URL: https://github.com/apache/airflow/issues/59707#issuecomment-3916699145
Same issue on **v3.1.7** with apache-airflow-providers-celery **3.15.2**.
Works fine without --celery-hostname
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org