Skip to content

fix: preserve root-cause errors in KMSMasterKey exception chaining - #815

Open
lucasmcdonald3 wants to merge 2 commits into
masterfrom
arpit-kms-fix-clean
Open

fix: preserve root-cause errors in KMSMasterKey exception chaining#815
lucasmcdonald3 wants to merge 2 commits into
masterfrom
arpit-kms-fix-clean

Conversation

@lucasmcdonald3

Copy link
Copy Markdown
Contributor

Fixes #774. Original contribution by @arpitjain099 in #807.

KMSMasterKey caught boto3 ClientError (and KeyError) on the
generate_data_key, encrypt, and decrypt calls and re-raised its own
GenerateKeyError / EncryptKeyError / DecryptKeyError without chaining the
original exception. Because the re-raise used a bare "raise SomeError(...)"
instead of "raise SomeError(...) from error", the re-raised exception's
__cause__ was None and the underlying KMS failure (for example an
AccessDeniedException) was dropped from the traceback. Callers were left
debugging in the dark with only the generic "unable to ... data key"
message.

Add "from error" at the three boto-call catch sites so the original
exception is preserved as __cause__. The raised exception type and message
are unchanged, so this is backward compatible; it only adds the chained
cause to the traceback.

Includes regression tests asserting __cause__ is the original ClientError
for the generate, encrypt, and decrypt paths.

Fixes #774

Signed-off-by: Arpit Jain <arpitjain099@gmail.com>
@lucasmcdonald3
lucasmcdonald3 requested a review from a team as a code owner August 26, 2026 21:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

KMSMasterKey swallows root cause errors

2 participants