eLod

Just to be clear, by anycable i rather mean anycable-rails as that is where these compatibility checks live. On second thought maybe this (anycable-rails) is the best place to add...

yes good point, if you agree i can create a PR sometimes tomorrow on `anycable-rails`. do you prefer creating an issue on `anycable-rails` also?

Trying to understand what is the best way to check if the testing part is applied, i am not sure if i understood you correctly, initially i thought we could...

Maybe using a different instance variable name like `@_stubbed_streams` would lower the name clash risk so that it can be used unconditionally (and even documented in testing guide so users...

@benjaminabel could you make your version accessible somehow? i can't npm install it from github, as it doesn't prepare the files with babel, so it ends up with the noop...

checked commenting out the `executions` from `SERIALIZATION_FILTERED_KEYS` and the override with `job_executions` in `JobWrapper#perform` makes it work as expected (obviously this simply ignores the value sent in headers). upon further...

well for me `retry_on` is the better/preferred way. first it's consistent, not locking into the backend's mechanism, so i am free to switch between sidekiq and cloudtasker and be confident...

just checked with sidekiq, and can confirm, it works as described, e.g. with `retry_on Exception, wait: 5.seconds, attempts: 3` i see the 3 runs with `executions` 1, 2 and 3,...

i can cook up a PR for this the next week, do you have any suggestions? should i just ignore the values from headers (when using the JobWrapper only, so...

I think the instructions in multiple languages is a nice addition, however as you mention the readme would quickly become a mess if it would include all the translations for...