Support multiple current attributes in middleware

[manu3569]

Currently, when calling Sidekiq::CurrentAttributes.persist(...) for multiple current attributes, the middleware doesn't correctly load the serialized data in the server middleware. In fact, it fails because the attributes from the first current attribute are used for "rehydrating" the second one.

The backwards compatible solution in this PR allows for a hash argument to be passed to the aforementioned method, with a key that is used in the jobs hash.

Sidekiq::CurrentAttributes.persist({
  cattr: "Myapp::Current",
  cattr_other: "Myapp::OtherCurrent"
})

[mperham]

when calling Sidekiq::CurrentAttributes.persist(...) for multiple current attributes

But why do you have multiple?

[mperham]

And your suggestion supports 2. What if I want 3?

[manu3569]

when calling Sidekiq::CurrentAttributes.persist(...) for multiple current attributes

But why do you have multiple?

In our case, we need to handle global state for two separate concerns, each with their own CurrentAttribute class.

---

And your suggestion supports 2. What if I want 3?

The proposed solution supports an arbitrary number of CurrentAttributes – one per key/value pair in the argument hash.

Sidekiq::CurrentAttributes.persist({
  cattr: "Myapp::Current",
  cattr_other: "Myapp::OtherCurrent",
  cattr_three: "Myapp::ThirdCurrent",
  cattr_fourth: "Myapp::FourthCurrent",
  ...
})

[mperham]

I understand your usecase. I don't like making the user configure the attribute name. I'm wondering if it would be simpler to do something like:

Sidekiq::CurrentAttributes.persist("Myapp::Current", "Myapp::OtherCurrent")

The first would be stored in cattr so it is backwards compatible with jobs already persisted in Redis. The second and beyond would be stored at cattr_1, cattr_2, etc. Effectively zero-based array indexes. You could add a new CurrentAttribute instance to the list and existing jobs data will remain backwards compatible. You could not change the ordering of attributes without breaking existing data.

WDYT?

[manu3569]

You could not change the ordering of attributes without breaking existing data.

That was the main reason I proposed the user defined key, but maybe documenting the caveat about changing order is good enough.

Do you prefer the suggested variable length method signature over accepting an array in the first position? We currently have the signature below, and we would need to type check the last argument to see if it's a config of a class string.

def persist(klass, config = Sidekiq.default_configuration)

Let me know how to proceed, and I'll make the changes. Thanks!

[mperham]

I think a single klass_or_array argument would be my initial thought but push back if there’s a good reason to.

[manu3569]

Made the suggested updates. Please, let me know if it's acceptable for merging now or if further tweaks are needed. Thanks!