I hadn't thought of using something like this for mitigating outages. Do you mind elaborating on that a bit more?
Currently there isn't a simple way to switch off the debug mode. So if `sst start` deploys the Lambda with the debug mode, `sst deploy` will disable it by putting the original Lambda back. But your idea of switching it on and off should work!
For the IAM portion, we are don't use the IAM credentials of the local machine while executing the Lambda. We use the credentials of the original Lambda. This allows for testing against the right credentials.
Appreciate the feedback! If you've have any questions or are curious about the internals, I'd love to hear from you jay@anoma.ly
Sorry, more investigation prior to mitigation than mitigation. I think moving the lambda aspects of sst to a lambda extension would allow for a workflow like this:
1. Find production issues
2. Replicate production issues in user facing tools
3. Run a local `sst start <fn> --filter '.userId == 'my-user-id'` to have remote <fn> connect to my local for any requests that match `evt.userId == 'my-user-id'`
4. Replicate issue and debug with the request sent to this particular lambda, potentially many calls away from the user action
5. Patch and deploy.
Being able to debug in situ would be fairly incredible in a complex application.
None of that is meant to take away at all from what you've built. What you have here is really awesome and I'm excited to use it.
I hadn't thought of using something like this for mitigating outages. Do you mind elaborating on that a bit more?
Currently there isn't a simple way to switch off the debug mode. So if `sst start` deploys the Lambda with the debug mode, `sst deploy` will disable it by putting the original Lambda back. But your idea of switching it on and off should work!
For the IAM portion, we are don't use the IAM credentials of the local machine while executing the Lambda. We use the credentials of the original Lambda. This allows for testing against the right credentials.
Appreciate the feedback! If you've have any questions or are curious about the internals, I'd love to hear from you jay@anoma.ly