README.md in resque-heroku-signals-2.1.0 vs README.md in resque-heroku-signals-2.2.0

- old
+ new

@@ -1,5 +1,8 @@ +[![Gem Version](https://badge.fury.io/rb/resque-heroku-signals.svg)](https://badge.fury.io/rb/resque-heroku-signals) +[![Ruby](https://github.com/iloveitaly/resque-heroku-signals/actions/workflows/ci.yml/badge.svg)](https://github.com/iloveitaly/resque-heroku-signals/actions/workflows/ci.yml) + # resque-heroku-signals This gem patches resque to be compatible with the Heroku platform. Specifically it modifies the UNIX signaling logic to be compatible with the Heroku worker shutdown process. @@ -21,10 +24,10 @@ Heroku sends a `TERM` signal to a process before hard killing it. If your job communicates with slow external APIs, you may want to make sure you have enough time to receive and handle the response from the external system before executing the API requests. Ideally, using an idempotency key with each external API request is the best way to ensure that a given API request only runs. However, depending on your application logic this may not be practical and knowing if a process will be terminated in less than 30s by Heroku is a useful tool. -Use `Resque.heroku_will_terminate?` to determine if Heroku will terminate your process within 30s. +Use `Resque.heroku_will_terminate?` to determine if Heroku will terminate your process within 30s. ## Example Procfile ``` worker: env QUEUE=* TERM_CHILD=1 INTERVAL=0.1 RESQUE_PRE_SHUTDOWN_TIMEOUT=20 RESQUE_TERM_TIMEOUT=8 bundle exec rake resque:work