fix: preserve root-cause errors in KMSMasterKey exception chaining#809
Merged
Conversation
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
approved these changes
Jun 23, 2026
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
3 participants
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.
Copy of #807 so that CI can run with the correct permissions.
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
Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Check any applicable: