Surface remote-log upload failures via structured warnings#66571
Merged
vatsrahul1001 merged 2 commits intoMay 19, 2026
Conversation
`upload_to_remote()` silently returned in three failure paths (handler load failure, log-path resolution exception, handler.upload exception) with no signal to the operator that logs were not reaching the remote system. The supervisor's `_upload_logs` already logs the outermost exception, but the inner paths inside `upload_to_remote()` were silent — so a misconfigured remote handler or a transient remote-system outage would degrade silently while local-only logs continued. Add a dedicated `airflow.logging.remote` structlog logger and emit a `log.warning` at each of the three failure paths with the TI id and the underlying error string. No behaviour change otherwise — failures still fall through softly so a bad remote handler doesn't abort the task lifecycle. Reported by the L3 ASVS sweep at apache/tooling-agents#24 (FINDING-004).
potiuk
force-pushed
the
fix/tasksdk-remote-log-load-warning
branch
from
c33b0a4 to
313bc16
Compare
Member
Author
|
I'd love to get this one merged — and would love it in 3.2.2 if it's not too late. cc @vatsrahul1001 (3.2.2 RM) Drafted-by: Claude Code (Opus 4.7); reviewed by @potiuk before posting |
vatsrahul1001
approved these changes
May 18, 2026
Lee-W
reviewed
May 18, 2026
Lee-W
reviewed
May 18, 2026
jason810496
approved these changes
May 18, 2026
Contributor
|
@potiuk can you address comments? |
amoghrajesh
reviewed
May 19, 2026
amoghrajesh
left a comment
amoghrajesh
left a comment
Contributor
There was a problem hiding this comment.
Can we also have a test pls?
- Use ti.id directly (available since 3.0) instead of getattr fallback. - Pass exc_info=exc to structlog so the traceback is preserved on path-resolution and upload failures. - Trim past-tense from the docstring comment. - Add tests covering the three failure paths and the silent success / no-path cases.
Member
Author
|
Addressed in 9c39993:
Drafted-by: Claude Code (Opus 4.7); reviewed by @potiuk before posting |
Lee-W
approved these changes
May 19, 2026
Contributor
Backport successfully created: v3-2-testNote: As of Merging PRs targeted for Airflow 3.X In matter of doubt please ask in #release-management Slack channel.
|
vatsrahul1001
pushed a commit
that referenced
this pull request
May 19, 2026
#66571) (#67172) * Surface remote-log upload failures via structured warnings `upload_to_remote()` silently returned in three failure paths (handler load failure, log-path resolution exception, handler.upload exception) with no signal to the operator that logs were not reaching the remote system. The supervisor's `_upload_logs` already logs the outermost exception, but the inner paths inside `upload_to_remote()` were silent — so a misconfigured remote handler or a transient remote-system outage would degrade silently while local-only logs continued. Add a dedicated `airflow.logging.remote` structlog logger and emit a `log.warning` at each of the three failure paths with the TI id and the underlying error string. No behaviour change otherwise — failures still fall through softly so a bad remote handler doesn't abort the task lifecycle. Reported by the L3 ASVS sweep at apache/tooling-agents#24 (FINDING-004). * Address review feedback on remote-log upload warnings - Use ti.id directly (available since 3.0) instead of getattr fallback. - Pass exc_info=exc to structlog so the traceback is preserved on path-resolution and upload failures. - Trim past-tense from the docstring comment. - Add tests covering the three failure paths and the silent success / no-path cases. (cherry picked from commit ef87426) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
vatsrahul1001
pushed a commit
that referenced
this pull request
May 20, 2026
#66571) (#67172) * Surface remote-log upload failures via structured warnings `upload_to_remote()` silently returned in three failure paths (handler load failure, log-path resolution exception, handler.upload exception) with no signal to the operator that logs were not reaching the remote system. The supervisor's `_upload_logs` already logs the outermost exception, but the inner paths inside `upload_to_remote()` were silent — so a misconfigured remote handler or a transient remote-system outage would degrade silently while local-only logs continued. Add a dedicated `airflow.logging.remote` structlog logger and emit a `log.warning` at each of the three failure paths with the TI id and the underlying error string. No behaviour change otherwise — failures still fall through softly so a bad remote handler doesn't abort the task lifecycle. Reported by the L3 ASVS sweep at apache/tooling-agents#24 (FINDING-004). * Address review feedback on remote-log upload warnings - Use ti.id directly (available since 3.0) instead of getattr fallback. - Pass exc_info=exc to structlog so the traceback is preserved on path-resolution and upload failures. - Trim past-tense from the docstring comment. - Add tests covering the three failure paths and the silent success / no-path cases. (cherry picked from commit ef87426) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
vatsrahul1001
pushed a commit
that referenced
this pull request
May 20, 2026
#66571) (#67172) * Surface remote-log upload failures via structured warnings `upload_to_remote()` silently returned in three failure paths (handler load failure, log-path resolution exception, handler.upload exception) with no signal to the operator that logs were not reaching the remote system. The supervisor's `_upload_logs` already logs the outermost exception, but the inner paths inside `upload_to_remote()` were silent — so a misconfigured remote handler or a transient remote-system outage would degrade silently while local-only logs continued. Add a dedicated `airflow.logging.remote` structlog logger and emit a `log.warning` at each of the three failure paths with the TI id and the underlying error string. No behaviour change otherwise — failures still fall through softly so a bad remote handler doesn't abort the task lifecycle. Reported by the L3 ASVS sweep at apache/tooling-agents#24 (FINDING-004). * Address review feedback on remote-log upload warnings - Use ti.id directly (available since 3.0) instead of getattr fallback. - Pass exc_info=exc to structlog so the traceback is preserved on path-resolution and upload failures. - Trim past-tense from the docstring comment. - Add tests covering the three failure paths and the silent success / no-path cases. (cherry picked from commit ef87426) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
vatsrahul1001
pushed a commit
that referenced
this pull request
May 21, 2026
#66571) (#67172) * Surface remote-log upload failures via structured warnings `upload_to_remote()` silently returned in three failure paths (handler load failure, log-path resolution exception, handler.upload exception) with no signal to the operator that logs were not reaching the remote system. The supervisor's `_upload_logs` already logs the outermost exception, but the inner paths inside `upload_to_remote()` were silent — so a misconfigured remote handler or a transient remote-system outage would degrade silently while local-only logs continued. Add a dedicated `airflow.logging.remote` structlog logger and emit a `log.warning` at each of the three failure paths with the TI id and the underlying error string. No behaviour change otherwise — failures still fall through softly so a bad remote handler doesn't abort the task lifecycle. Reported by the L3 ASVS sweep at apache/tooling-agents#24 (FINDING-004). * Address review feedback on remote-log upload warnings - Use ti.id directly (available since 3.0) instead of getattr fallback. - Pass exc_info=exc to structlog so the traceback is preserved on path-resolution and upload failures. - Trim past-tense from the docstring comment. - Add tests covering the three failure paths and the silent success / no-path cases. (cherry picked from commit ef87426) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
6 tasks
Member
|
Two issues: One: This happens for every task when remote logging is not configured. Two: this only appears in the worker logs, which isn't visible to 99% of Airflow users. Was that your intention with this log, or were you expecting it to be visible in task logs? |
Member
|
@potiuk ^^ |
1 task
Member
Author
|
@ashb you were right — sorry for the unnecessary noise. The warnings fired for every task on installs without remote logging (a missing handler is the default, not a failure) and only reached worker stdout, not the task logs operators actually read. I tried a more targeted fix — silencing the no-handler case and routing genuine upload failures through the task's own logger so they'd show up in task logs — but it added more complexity than the defense-in-depth was worth. Reverting the whole change is the best solution for now: #68371. We can revisit surfacing real remote-upload failures later with a design that doesn't trip on the common no-remote-logging case. Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting |
ashb
pushed a commit
that referenced
this pull request
Jun 11, 2026
…66571)" (#68371) This reverts commit ef87426. The remote-log upload warnings fired for every task on installs without remote logging configured (a missing handler is the default, not a failure) and were emitted through a dedicated "airflow.logging.remote" logger that only reaches worker stdout, not the task logs operators actually read. The whole change is withdrawn rather than patched.
7 tasks
imrichardwu
pushed a commit
to imrichardwu/airflow
that referenced
this pull request
Jun 16, 2026
…pache#66571)" (apache#68371) This reverts commit ef87426. The remote-log upload warnings fired for every task on installs without remote logging configured (a missing handler is the default, not a failure) and were emitted through a dedicated "airflow.logging.remote" logger that only reaches worker stdout, not the task logs operators actually read. The whole change is withdrawn rather than patched.
dingo4dev
pushed a commit
to dingo4dev/airflow
that referenced
this pull request
Jun 16, 2026
…pache#66571)" (apache#68371) This reverts commit ef87426. The remote-log upload warnings fired for every task on installs without remote logging configured (a missing handler is the default, not a failure) and were emitted through a dedicated "airflow.logging.remote" logger that only reaches worker stdout, not the task logs operators actually read. The whole change is withdrawn rather than patched.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
upload_to_remote()silently returned in three failure paths (handler load failure, log-path resolution exception,handler.uploadexception) with no signal to the operator that logs were not reaching the remote system. The supervisor's_upload_logsalready logs the outermost exception, but the inner paths insideupload_to_remote()were silent — so a misconfigured remote handler or a transient remote-system outage would degrade silently while local-only logs continued.Fix
Add a dedicated
airflow.logging.remotestructlog logger and emit alog.warningat each of the three failure paths with the TI id and the underlying error string. No behaviour change otherwise — failures still fall through softly so a bad remote handler doesn't abort the task lifecycle.Reported by
L3 ASVS sweep — apache/tooling-agents#24 (FINDING-004).
Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Opus 4.7) following the guidelines