Conversation
Add Lambda resource matching in the proxy handler (FunctionName/ARN-based) and comprehensive integration tests covering basic proxying, read-only mode, and resource name pattern matching. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
1204f7b to
976911c
Compare
| "PartiQLSelect", | ||
| }: | ||
| return True | ||
| if context.service.service_name == "lambda" and operation_name in { |
There was a problem hiding this comment.
I'm not quite sure if we should consider the invoking of lambdas as a "read" operation.
Running a lambda can have many side-effects. I wouldn't expect the lambda to be called when I use read-only mode. Especially in the era of AI-agents, this can be very problematic for a user that may have thought that they give read-only access to the proxy.
Could we introduce some other mode specifically for cases like this? (like execute or invoke?)
There was a problem hiding this comment.
Thanks @nik-localstack - that's a great feedback actually. 👌 I've extended the logic (and docs in README) to include an execute flag that can be defined separately for read-only resources. 👍 Please take another look when you get a chance. 🙌
(btw, the proxy tests are currently disabled as we need to make some fixes related to recent localstack-core/CLI changes - will look into fixing that in a separate PR shortly..!)
ea3cea5 to
1031ed0
Compare
Lambda Invoke operations have side-effects and should not be treated as read operations. Removes them from _is_read_request and introduces a new 'invoke' config flag that explicitly allows invocations alongside read_only mode. Updates tests and README accordingly. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
1031ed0 to
63211db
Compare
Add Lambda resource matching in the proxy handler (FunctionName/ARN-based) and comprehensive integration tests covering basic proxying, read-only mode, and resource name pattern matching.