Failed to fetch log file from worker because webserver did not search the right worker.

[pretendhigh]

Apache Airflow version:
Airflow 2.1.0

Environment:

• OS (e.g. from /etc/os-release): Ubuntu 20
• Kernel (e.g. uname -a): 5.4.0-48-
• Install tools: pip
• Others: python3.8, use celeryexcutor, 3 worker: hadoop03,hadoop04,hadoop05, webserver:hadoop03

What happened:
When a task retry a lot of times, some log show error:

*** Log file does not exist: /home/hadoop/airflow/logs/retry4/print_date/2021-06-14T00:00:00+00:00/10.log
*** Fetching from: http://hadoop05:8793/log/retry4/print_date/2021-06-14T00:00:00+00:00/10.log
*** Failed to fetch log file from worker. 404 Client Error: NOT FOUND for url: http://hadoop05:8793/log/retry4/print_date/2021-06-14T00:00:00+00:00/10.log

It is because the log retry4/print_date/2021-06-14T00:00:00+00:00/10.log is not in hadoop05 and it is in hadoop04. we can find log file /home/hadoop/airflow/logs/retry4/print_date/2021-06-14T00:00:00+00:00/10.log in hadoop04.
As we can see, the task's latest log is in hadoop05. I guess webserver firstly search log from local host, secondly it will search host from the latest hostname nomatter if other previous logs is in the latest hostname.
We can get the task's laest log in hadoop05.


We can also get previous log in webserver host hadoop03.

But We can not get previous log which is not in hadoop05 and hadoop03(webserver host). Because webserver try to search log from hadop05 but not hadoop04 which the log is really in.

What you expected to happen:
Webserver should try to get log from ther right worker server but not hadoop05 which the latest log is in.

How to reproduce it:
You can try these dags in a airflow cluster that has more than 3 celery worker node.

#
# Licensed to the Apache Software Foundation (ASF) under one
# or more contributor license agreements.  See the NOTICE file
# distributed with this work for additional information
# regarding copyright ownership.  The ASF licenses this file
# to you under the Apache License, Version 2.0 (the
# "License"); you may not use this file except in compliance
# with the License.  You may obtain a copy of the License at
#
#   http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing,
# software distributed under the License is distributed on an
# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
# KIND, either express or implied.  See the License for the
# specific language governing permissions and limitations
# under the License.

"""
### Tutorial Documentation
Documentation that goes along with the Airflow tutorial located
[here](https://airflow.apache.org/tutorial.html)
"""
# [START tutorial]
# [START import_module]
from datetime import timedelta
from textwrap import dedent

# The DAG object; we'll need this to instantiate a DAG
from airflow.models import DAG, Variable
from airflow.operators.bash_operator import BashOperator
# Operators; we need this to operate!
from airflow.utils.dates import days_ago

# [END import_module]

# [START default_args]
# These args will get passed on to each operator
# You can override them on a per-task basis during operator initialization
default_args = {
    'owner': 'airflow',
    'depends_on_past': False,
    'email': ['[email protected]'],
    'email_on_failure': False,
    'email_on_retry': False,
    'retries': 10,
    'retry_delay': timedelta(minutes=1),
    # 'queue': 'bash_queue',
    # 'pool': 'backfill',
    # 'priority_weight': 10,
    # 'end_date': datetime(2016, 1, 1),
    # 'wait_for_downstream': False,
    # 'dag': dag,
    # 'sla': timedelta(hours=2),
    # 'execution_timeout': timedelta(seconds=300),
    # 'on_failure_callback': some_function,
    # 'on_success_callback': some_other_function,
    # 'on_retry_callback': another_function,
    # 'sla_miss_callback': yet_another_function,
    # 'trigger_rule': 'all_success'
}
# [END default_args]

# [START instantiate_dag]
with DAG(
    'retry4',
    default_args=default_args,
    description='A simple tutorial DAG',
    schedule_interval=timedelta(days=1),
    start_date=days_ago(2),
    tags=['example'],
) as dag:
    # [END instantiate_dag]

    # t1, t2 and t3 are examples of tasks created by instantiating operators
    # [START basic_task]
    t1 = BashOperator(
        task_id='print_date',
        bash_command='exit 1',
    )

    t2 = BashOperator(
        task_id='sleep',
        depends_on_past=False,
        bash_command='sleep 5',
        retries=3,
    )
    # [END basic_task]

    # [START documentation]
    t1.doc_md = dedent(
        """\
    #### Task Documentation
    You can document your task using the attributes `doc_md` (markdown),
    `doc` (plain text), `doc_rst`, `doc_json`, `doc_yaml` which gets
    rendered in the UI's Task Instance Details page.
    ![img](http://montcs.bloomu.edu/~bobmon/Semesters/2012-01/491/import%20soul.png)

    """
    )

    dag.doc_md = __doc__  # providing that you have a docstring at the beggining of the DAG
    dag.doc_md = """
    This is a documentation placed anywhere
    """  # otherwise, type it like this
    # [END documentation]

    # [START jinja_template]
    templated_command = dedent(
        """
    {% for i in range(5) %}
        echo "{{ ds }}"
        echo "{{ macros.ds_add(ds, 7)}}"
        echo "{{ params.my_param }}"
    {% endfor %}
    """
    )

    t3 = BashOperator(
        task_id='templated',
        depends_on_past=False,
        bash_command=templated_command,
        params={'my_param': 'Parameter I passed in'},
    )
    # [END jinja_template]

    t1 >> [t2, t3]
# [END tutorial]

Anything else we need to know:
I have test in airflow2.0.2 and airflow1.10.12, this bug always exists.

[boring-cyborg[bot]]

Thanks for opening your first issue here! Be sure to follow the issue template!

[uranusjr]

Is this the same as #15767?

[pretendhigh]

Is this the same as #15767?

Yes, I thinks it is almostly the same.

[pavel-lexyr]

Can confirm it's still present in v2.2.3.

[eladkal]

Can you please check if this issue still happens on latest Airflow version?

[santoshdms2003]

It is present in Airflow 2.5.3 version also

[potiuk]

I do recall it's been mitigated in later versions of Airflow, so indeed checking it with latest version is a good idea. Converting it into discussion.

[potiuk]

Can you please open an issue with all details , circumstances (what exactly you see as an issue and why) @spasalkar-uptycs. The more you help with providing evidences, the easier it wil be to investigate it and you will help others in solving the problem.

[spasalkar-uptycs]

@potiuk I see same condition as above 3 celery worker node & one of them is also master. Deployed using the docker-compose

[spasalkar-uptycs]

I will create issue with above details in ticket

[potiuk]

The more details, the betteer. And ideally a way to reproduce it.

[potiuk]

MInimum reproducible steps is the key to be able to diagnose it.

[Gollum999]

@potiuk @eladkal I just confirmed that this is still happening in Airflow 2.5.1. Steps to reproduce are the same as are shown in #26069.

[potiuk]

Is it possible to create a new issue with details similar to the original one (including also logs from workers where the webserver gets the logs - that would massively helpe with diagnosing it).

[Gollum999]

Apologies for the delay, but the new issue is here: #30743

I unfortunately couldn't find any useful logs, including from the webserver and from the workers, so this report looks pretty similar to all of the previous reports.

[potiuk]

Yeah. I tihnk the diagnosis of your is right and we even started to think about different handling for try_nums in related PR (see comment in your issue). Possibly we will fix it in 2.7