Fix provider error messages rendering as a tuple instead of the value - #73296
Merged
Merged
Conversation
vatsrahul1001
approved these changes
Sep 20, 2026
Contributor
|
Need to resolve conflict in test, otherwise LGTM! |
kaxil
force-pushed
the
fix-exception-format-args
branch
from
September 20, 2026 11:58
3e53736 to
280cdcb
Compare
1 task
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
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.
Three
raisesites pass%s-style format arguments to the exception constructor, which does not interpolate them. The extra arguments land inargs[1:]and the message renders as a tuple repr, so the user sees the format string rather than their own values:The
self.log.info("%s completed successfully as %s found.", ...)on the line below the first one is correct and is left alone: Airflow's structlog processor appliesmsg % args, so the logging form interpolates. Only the exception constructor does not.Two of the three lines had no test reading the message, and the
connection_config is Nonebranch was not reached by any test at all, so both now have one. The third already had two assertions, but they matched on a prefix that appears in the tuple repr as well and so passed either way; they now require the interpolated form, and fail without the fix.Worth knowing before this is merged: it is coupled to #73076, which adds a prek hook plus
generated/known_exception_format_args.txtrecording exactly these three files at count 1, and says it does not fix them. Whichever lands second has to update the other -- if #73076 goes first, three counts need decrementing here; if this goes first, its allowlist is stale and the hook fails. I am happy to rebase on it in either order. Separately, #64941 movesdatafusion/object_storage_provider.pyinto the amazon provider, so that one line may need rehoming.