Unsure. Put together a demo test project.
The Readme covers how I tested it. Here’s the relevant part.
Session Output
❯ jets console
Jets booting up in development mode!
irb(main):001:0> 5.times { |i| DispatcherJob.perform_now(:dispatch, test: "message #{i+1}") }
Dispatched from job: {"test"=>"message 1"}
Dispatched from job: {"test"=>"message 2"}
Dispatched from job: {"test"=>"message 3"}
Dispatched from job: {"test"=>"message 4"}
Dispatched from job: {"test"=>"message 5"}
=> 5
irb(main):002:0>
Tail with a grep test
❯ jets logs -f -n courier_job-process | grep test
Tailing logs for /aws/lambda/testapp-dev-courier_job-process
2023-12-21 15:18:56 UTC CourierJob sqs_event_payload: {"test"=>"message 1"}
2023-12-21 15:18:56 UTC CourierJob sqs_event_payload: {"test"=>"message 2"}
2023-12-21 15:18:56 UTC CourierJob sqs_event_payload: {"test"=>"message 3"}
2023-12-21 15:18:56 UTC CourierJob sqs_event_payload: {"test"=>"message 4"}
2023-12-21 15:18:56 UTC CourierJob sqs_event_payload: {"test"=>"message 5"}
It confirms that messages are being delivered.
Related Though a Little Off Topic
I also noticed this post: Store Shared Resource Name Store?. There’s a caveat with the List.lookup method.
The lookup method works to get the SQS queue info by making an API call to CloudFormation to grab the output. He was running into CloudFormation rate limits. He ended up storing the info in an SSM param store. You could also store it in a config file to look up. It’s not ideal, but there are ways.
I’m also thinking that it’ll be good to add some caching for the lookup call. Jets can cache it in the “cold start/shared memory” space. So it’s only looked up once until the Lambda Function has been “rotated” or cold-started. Folks have measured cold-start frequency and report that it’s 45-60m. That should reduce the Cloudformation calls dramatically since it’ll only make the CloudFormation describe call once every 45-60m instead of every request.