Skip to content

Do not show @timestamp in logs in UI - #70790

Merged
potiuk merged 2 commits into
apache:mainfrom
k-popov:no_at_timestamp_in_log
Aug 1, 2026
Merged

Do not show @timestamp in logs in UI#70790
potiuk merged 2 commits into
apache:mainfrom
k-popov:no_at_timestamp_in_log

Conversation

@k-popov

@k-popov k-popov commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

When:

  • airflow3 is deployed into k8s with community helm chart
  • airflow is configured to read logs from elasticsearch where fluentbit is pushing them by reading output of task pods
  • configuration is the following (partial)
[core]
remote_logging = True
[elasticsearch]
json_format = True
write_stdout = True

after a task is already finished an additional @timestamp field is displayed in web UI which duplicates information in the main timestamp (at the beginning of line):
before

The patch is not including the @timestamp field itself but still performs mapping it into timestamp field is the latter is not present. With the proposed patch there is no duplicated information on timestamp, the log looks cleaner:
after


Was generative AI tooling used to co-author this PR?
  • Yes (please specify the tool below)

  • Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
  • For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
  • When adding dependency, check compliance with the ASF 3rd Party License Policy.
  • For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

@boring-cyborg

boring-cyborg Bot commented Jul 30, 2026

Copy link
Copy Markdown

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

  • Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
  • In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
  • Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
  • Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
  • Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
  • Be sure to read the Airflow Coding style.
  • Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
    Apache Airflow is a community-driven project and together we are making it better 🚀.
    In case of doubts contact the developers at:
    Mailing List: dev@airflow.apache.org
    Slack: https://s.apache.org/airflow-slack

@k-popov
k-popov force-pushed the no_at_timestamp_in_log branch from 54b927c to b50a1b0 Compare July 30, 2026 19:21
Comment thread providers/opensearch/src/airflow/providers/opensearch/log/os_task_handler.py Outdated

@potiuk potiuk left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, and precisely diagnosed. The old filter kept @timestamp in the output set and only removed it via .pop() when timestamp was absent — so whenever a hit carried both, which is the normal case once a shipper adds @timestamp alongside the timestamp the supervisor already wrote, the pop never ran and the field leaked into the UI.

Reading it from hit_dict as a fallback source instead of filtering it in is the right shape, and the @timestamp-only path still maps correctly since TASK_LOG_FIELDS contains timestamp. Fixing both providers symmetrically with the same both-present regression test in each is exactly right.

I pushed the docstring fix myself so this didn't need another round-trip from you — the OpenSearch handler's docstring had picked up "ES" from the elasticsearch copy.


Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting

@potiuk
potiuk merged commit 915e61c into apache:main Aug 1, 2026
98 checks passed
@boring-cyborg

boring-cyborg Bot commented Aug 1, 2026

Copy link
Copy Markdown

Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants