Route pgjsonb database errors through Salt's logger instead of stderr#69049
Open
co-cy wants to merge 1 commit into
Open
Route pgjsonb database errors through Salt's logger instead of stderr#69049co-cy wants to merge 1 commit into
co-cy wants to merge 1 commit into
Conversation
`salt.returners.pgjsonb` had eight error-handling sites in `_get_serv`,
`_purge_jobs` and `_archive_jobs` that wrote `psycopg2.DatabaseError`
messages directly to `sys.stderr` and re-raised:
except psycopg2.DatabaseError as err:
error = err.args
sys.stderr.write(str(error))
cursor.execute("ROLLBACK")
raise err
On a daemonized master `sys.stderr` is captured by systemd's journal
(or worse, /dev/null), bypassing the configured `log_file` /
`log_level_logfile` and syslog. Operators that scrape Salt's log file
never see these errors, even though the rest of the file already uses
`log.error` (e.g. `clean_old_jobs`).
The local `error = err.args` assignment is dead -- only `str(err.args)`
is written, then the variable is unused. Also drop `import sys`,
which becomes unused after the migration.
Replace each call with `log.exception(...)` carrying a description of
the operation that failed, so the traceback is preserved in the log.
Behaviour (rollback, re-raise) is unchanged. The asymmetric
`except Exception` block on `_archive_jobs` jids-insert is updated to
the same pattern but kept in place (its scope is PR-7, not this PR).
Add three behavioural tests with `caplog`: one each for `_get_serv`,
`_purge_jobs` and `_archive_jobs` confirming the error reaches Salt's
logger, the transaction is rolled back, and the exception propagates.
Refs: saltstack#69048
This was referenced May 5, 2026
Open
Open
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.
What does this PR do?
salt/returners/pgjsonb.pyhas eight error-handling sites in_get_serv,_purge_jobsand_archive_jobsthat writepsycopg2.DatabaseErrormessages directly tosys.stderrand re-raise. On a daemonized mastersys.stderrends up in systemd's journal at best (or/dev/nullat worst) — never in the configuredlog_file/ syslog destination. Operators that scrape Salt's log file have no idea those database errors happened.This PR replaces every
sys.stderr.writewithlog.exception(...)carrying a description of the operation that failed, so the message and a full traceback reach Salt's configured log destination. The deaderror = err.argsassignment is removed, the now-unusedimport sysis dropped, andraise erris normalised to bareraiseto preserve the original traceback. Behaviour (rollback, re-raise) is unchanged — only the visibility of the error changes.The asymmetric
except Exceptionblock on_archive_jobsjids-insert is updated to uselog.exceptionfor consistency, but it is left in place for the same scope reason — sorting that asymmetry out belongs in a separate PR.What issues does this PR fix or reference?
Fixes #69048
Previous Behavior
The error message went to stderr (journal / /dev/null) and never to the configured Salt log. The exception still propagated, but with a synthetic traceback (because of
raise errinstead of bareraise).New Behavior
The error message and the full traceback are routed through
log.exceptionto Salt's configured logger. The original traceback is preserved.Merge requirements satisfied?
changelog/69048.fixed.mdtests/pytests/unit/returners/test_pgjsonb.py:test__purge_jobs_logs_via_salt_logger_and_reraises_on_db_errortest__archive_jobs_logs_via_salt_logger_and_reraises_on_db_errortest__get_serv_logs_via_salt_logger_and_reraises_on_yield_errorCommits signed with GPG?
No.