You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: Allow short function names in queue consumer config (#1206)
Lambda Wrapper's current documentation for "direct"-mode offline SQS
is incorrect: queue consumer names must be the full deployed function
name generated by Serverless, typically `service-stage-FunctionName`,
instead of just `FunctionName`.
However, this approach is more difficult for the developer. In some
of our services, this had been set up with hardcoded stage values,
leading to unexpected issues when trying to simulate stages other than
`dev` locally.
This PR allows `SQSService` to add the necessary prefix to queue
consumer function names, making the previously incorrect example in the
documentation work.
In order to maintain backwards compatibility, the prefix will not be
added if it is already present. Correctly configured projects can
continue to function, while projects that are broken (or broken in some
stages where stage was hardcoded) will continue to be broken.
Some design decisions:
- I've placed the helper for getting the Lambda function name prefix
into a public method of `DependencyInjection`, alongside the `isOffline`
helper. It's not SQS-specific, and will be helpful in other scenarios
where we want to invoke one Lambda function from another.
- All changes in `SQSService` are within the `publishOffline` method. I
initially considered mutating the SQS config object within the
constructor so that all `queueConsumer` values were converted to full
function names (requiring no changes to `publishOffline`). However, in a
deployed environment, this creates unnecessary additional work within
every Lambda invocation.
Jira: [ENG-3396]
[ENG-3396]: https://comicrelief.atlassian.net/browse/ENG-3396
//add an entry mapping each queue to its consumer function name
128
124
submissions: 'SubmissionConsumer',
129
125
},
130
126
}
@@ -151,6 +147,8 @@ To take advantage of SQS emulation, you will need to do the following in your pr
151
147
152
148
3. If the triggered lambda incurs an exception, this will be propagated upstream, effectively killing the execution of the calling lambda.
153
149
150
+
4. Queue producer and consumer functions must not have custom deployed Lambda names.
151
+
154
152
### Local SQS mode
155
153
156
154
Use this mode by setting `LAMBDA_WRAPPER_OFFLINE_SQS_MODE=local`. Messages will still be sent to an SQS queue, but using a locally simulated version instead of AWS. This allows you to test your service using a tool like Localstack.
0 commit comments