Skip to content

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

Closed
lucasmcdonald3 wants to merge 2 commits into
masterfrom
arpitjain099-kms-exception-chaining-774
Closed

fix: preserve root-cause errors in KMSMasterKey exception chaining#814
lucasmcdonald3 wants to merge 2 commits into
masterfrom
arpitjain099-kms-exception-chaining-774

Conversation

@lucasmcdonald3

Copy link
Copy Markdown
Contributor

Issue #, if available:

774

Description of changes:

#807

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Check any applicable:

  • Were any files moved? Moving files changes their URL, which breaks all hyperlinks to the files.

arpitjain099 and others added 2 commits June 5, 2026 20:43
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>
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.

2 participants