Summary

Sidekiq::SortedEntry#reschedule writes the new score to Redis via zincrby but never updates @score, so the in-memory entry's #score and #at keep returning the stale (pre-reschedule) values:

entry = Sidekiq::ScheduledSet.new.first   # score => T0
entry.reschedule(Time.at(T0 + 500))
entry.score   # => T0 (stale, redis has T0+500)
entry.at      # => Time.at(T0) (stale)

The other SortedEntry mutators (add_to_queue/retry/kill/delete) all remove the entry from its set, so a stale entry there is moot. reschedule is the only mutator that keeps the job alive in the same set with a new score — making the drift between in-memory state and Redis a real footgun specifically here.

Fix: set @score = at.to_f after the zincrby.

Testing

Adds a focused regression test that re-reads entry.score / entry.at after reschedule and asserts they reflect the new time. Fails before the change and passes after. The existing "can reschedule jobs" test is unaffected (it re-iterates the set, so it always sees fresh entries from Redis).

bundle exec rake is green (standard + lint:herb + full suite).