If you're on a Rails 7 Application, I would probably not create custom channels if you can avoid it. Hotwire's Turbo has gotten us so far to where a lot of the manual channels are no longer needed and can exist in the background now through Turbo.

Did you deviate from the Dockerfile? Make sure that libpq-dev is being installed in the Dockerfile.

Make sure that you also have your database.yml updated for the Test Database. 

Do you have skip_before_action :verify_authenticity_token in the controller that Apple is calling?

  jomaestradama  You shouldn't be bringing in the two background workers unless you have a very specific use case. However, if you're transitioning from one to the other, just keep in mind that you can have only one ActiveJob adapter enabled at a time. I don't recommend trying to switch them on the fly as the jobs are getting processed as it could end up with some really strange situations where the wrong adapter is processing a job. You can always enqueue the jobs as you normally would without ActiveJob and just queue them up as if you weren't within a Rails application. But, this kind of circles back to why have two different kinds of background workers that are performing similar functionalities. One reason for two workers would be for something that had mission critical transactions. Think of it like a banking transaction where you needed something to be queued up with a critical need for ensuring that the job did not get lost. Using DelayedJob to persist the job information in the database could be a viable use case, but the other background jobs were of much less importance so Sidekiq is used for those.