lift
lift copied to clipboard
getlift
Queue: retry failed messages via a Lambda function instead of a local command
I am opening this issue to track a use case: retrying failed messages via a Lambda function.
Current behavior:
As a user, I can retry failed messages of a queue via: serverless queue:retry.
That command will connect to the SQS DLQ, fetch messages and move them to the main queue.
As such, the user running the command must have the AWS permissions to read/write those SQS queues.
New behavior:
On top of the existing command, there could be an alternative: the "retry" logic could run in a Lambda function.
That way, permissions to read/write SQS queues is limited to the Lambda function.
The Lambda function could be deployed by the queue construct: it wouldn't be a function users have to write.
The function could be triggered either manually by users (through the AWS console or API) or via a local command, e.g. serverless queue:retry-lambda:invoke (or whatever the name would be). That local command would invoke the Lambda function (not connect to SQS directly).
If this use case matches your needs please add 👍 on this issue and describe your situation in a comment. This helps prioritize new features.
I find this particularly useful in environment where CLI user has a limited set of permissions, i.e. production environments. I'm very much interested in such feature, but it'll also introduce for the first time in Lift maintenance lambdas. Those lambda will have a nodejs codebase - the Lift language - and may generate the same kind of interrogation than when custom resources where heavily relied on in the Serverless framework for non-provisionnable resources (aka eventbridge, s3, cognito).
Despite this disadvantage, I'm in favor of such behavior. It would as well need to be implemented for other commands ?
