Wait for queues to be idle.

[metaskills]

Followup from discussion in #250. Some background on this feature. At Custom Ink we are exploring migrating our "messaging" and "jobs" pods from K8s to Lambda Containers. We can do this using the same ECR images in our deploy pipeline leveraging internal tools and perhaps one day Amazon Controller for Kubernetes (ACK). Sounds complicated but at the end of the day we use the same ECR images on Lambda by changing the ENTRYPOINT and COMMAND. The result would be Rails application processes that respond to AMQP/EventBridge events and/or Sidekiq style jobs using managed AWS Resources and scale to 0 Compute without writing custom software or changing code per-runtime.

There are a few gotchas. Because AWS Lambda freezes the execution freezes the execution environment between requests, background processing by long running processes typically break down. A good example is NewRelic. Thankfully, they have an interface to flush the metric data. For Rails projects that are 100% on AWS Lambda, we use a SuckerPunch inspired gem called LambdaPunch. https://github.com/customink/lambda_punch

Would LambdaPunch work here? It totally could. But it would be another extension we would have to install in the container and require a bit more orchestration in things like our Rollbar config. It would also require a lot of event handling delegation code to to pass down the Lambda context. Ideally, it would be awesome if SuckerPunch had a flush/wait interface similar to NewRelic. So the proposed change would appear like this to us.

class MyJob < ApplicationJob
  after_perform do |_job| 
    NewRelic::Agent.agent.flush_pipe_data
    SuckerPunch::Queue.wait
  end

  def perform(event)
    # ...
  end
end

More On The Topic

In case you are curious, here is one open source project that leans into a mantra I call (container code need not care where containers are running) that helps AWS Lambda mimic encrypted environment variables using AWS Systems Manager which K8s secrets manager does.

https://github.com/customink/crypteia

This helps ensure container portability with no code changes and leans into twelve factor. This is not directly related to the pull request but thought it might be helpful to share since we are asking for an interface that SuckerPunch (free puppy) vs implementing an internal gem or per-project freedom patches. I hope this context is helpful.

Pull Request Next Steps

I did not see any tests for shutdown_all so added none here. I would totally be willing to add some tho using your feedback? Also, is the method name right? Should it be wait_all or something different?

[brandonhilkert]

Looks good to me. Let's:

• Merge in master and see a clean test run
• Add to the changlog
• Give a whirl at documenting the new method in the README

[metaskills]

Cool, I just got back from a few days off. Would you like me to do any of that work listed above in this PR or followup ones?

[metaskills]

I saw this test head failure but I think main is failing already? https://github.com/brandonhilkert/sucker_punch/runs/8102223916?check_suite_focus=true

[brandonhilkert]

If you could all posted, that’d be really helpful. I’ve fixed master (that’s where the test failure came from), so pulling master in should do the trick.

[metaskills]

WOW, I really love how GitHub makes that so easy. Just pushed a change with main up to date.

[metaskills]

Sorry, I misunderstood your request I just checked these boxes.

• ✅ Merge in master and see a clean test run
• ✅ Add to the changlog
• ✅ Give a whirl at documenting the new method in the README

What do you think of the new Queue Class Methods section in the README? Felt like an opportunity to document all those. I could change those around, format, text, etc. Lemme know and again, thank you.

[brandonhilkert]

3.1.0 has been released. Thanks!

[metaskills]

Thank you! Tested this out today in production. Things look to be working as expected. Really appreciate it.

[brandonhilkert]

No worries. Glad it helped!