Avoid hidden failures when dumping #38
Conversation
max-muoto
force-pushed
the
capture-any-non-zero-exit-code
branch
2 times, most recently
from
6a82b05 to
43c5008
Compare
pgclone/run.py
Outdated
| @@ -8,11 +8,24 @@ | |||
| from pgclone import exceptions, logging | |||
|
|
|||
|
|
|||
| def shell(cmd, ignore_errors=False, env=None): | |||
| def _is_pipefail_supported(): | |||
There was a problem hiding this comment.
set -o pipefail is supported in most POSSIX shell implementations at this point, it was added to the spec in 2022 - but the user could still be missing it
max-muoto
changed the title
max-muoto
force-pushed
the
capture-any-non-zero-exit-code
branch
from
39b00f6 to
275923b
Compare
| def _is_pipefail_supported() -> bool: | ||
| """Check if the current shell supports pipefail.""" | ||
| if sys.platform == "win32": | ||
| return False |
There was a problem hiding this comment.
you may need a pragma: no cover here for the coverage check
|
@max-muoto See this Stack Overflow thread for what I am talking about. Any idea if this may be a problem for |
Thanks for the callout, let me double check and get back to you here! |
I recently ran into an issue where we were getting silent failures despite
pg_dumpfailing. In particular had a client/server mismatch (client had a version of 16, with the server being on 17) - resulting in us creating empty dumps on S3.This PR sets pipefail when dumping to ensure capture failures in
pg_dump. Currently none of the integration tests interact with S3, but if we want something I'm happy to add something mocking out the storage layer to simulate piping even when dumping locally.