APIGW: fix TestInvokeMethod 500 failures#13207
Merged
Conversation
LocalStack Community integration with Pro 2 files 2 suites 17m 1s ⏱️ Results for commit ed9cd64. |
Test Results (amd64) - Integration, Bootstrap 5 files 5 suites 34m 50s ⏱️ Results for commit ed9cd64. |
cloutierMat
approved these changes
Sep 30, 2025
Member
cloutierMat
left a comment
There was a problem hiding this comment.
Thanks for jumping on this! 🙏 LGTM
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.
Motivation
As part of our weekly report, I've spotted 2 issues with APIGW
TestInvokeMethod:and this one:
The first one is because we probably didn't handle failed invocation, and always expected every failed to be present. We need to guard against None-values when calling
.get(), and improve it all together. The solution is not bullet proof, because to have perfect logging, we need to store the log as we progress in the invocation to be able to "stop" at the right moment, where the exception happens.The second one is because we did not handle the
ANYvalues properly, and also did not handle failures when the method would not exist.Changes
TestInvokeMethodand add some fallbacks