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 |
potiuk
added
the
backport-to-v3-2-test
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
Contributor
amoghrajesh
left a comment
amoghrajesh
left a comment
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>
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
5 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