Set, serialize, and deserialize Active Job scheduled_at as Time; deserialize enqueued_at as Time; deprecate setting scheduled_at= with numeric/epoch

[bensheldon]

Motivation / Background

This Pull Request has been created to make a job's scheduled_at value available during job execution by serializing/deserializing the value.

This PR also aligns the behavior of both scheduled_at and enqueued_at to use Time objects internally instead of epoch-second Floats or Strings. This change for scheduled_at should be transparent for users that are using the primary set(wait:, wait_until:) interface and is non-breaking if setting the value directly e.g. job.scheduled_at = 10.minutes.from_now.to_f. The adapter interface is unchanged: adapters still receive epoch-second Float params in enqueue_at.

Detail

This change was initially proposed by @adamnoto in #32071 (2018), and closed because scheduled_at was viewed as an implementation detail of the backend queue adapter.

I am reopening this PR because I believe there have been some changes in the ecosystem, and with Active Job, that warrant revisiting how scheduled_at is handled.

Ecosystem changes: I'll point to my own good_job backend, also skiplock, that are designed for Active Job, and did not exist at the time the previous PR was closed five years ago. With these Active Job-native adapters, scheduled_at is directly used for scheduled jobs, and rescheduled retries. I think Active Job is in a stronger position today to assert the value, and if not appropriate, adapters are able to override/re-assign the value before execution, for example, as they typically do job.provider_job_id

Active Job changes: There is a greater interface focus on the instance of ActiveJob::Base. For example, introducing #set and the interface for perform_all_later. It would be nice to have full symmetry of attributes set on an instance before enqueue to be available on the instance after enqueue during execution.

The inspiration for reopening this change was that I recently saw the sidekiq-expiring-job gem and thought that it would be nice if that could be easily implemented in an Active Job before_perform. e.g.

class ApplicationJob < ActiveJob::Base
  ExpiredJobError = Class.new(StandardError)

  discard_on ExpiredJobError
  
  before_perform do |job|
    raise ExpiredJobError if job.scheduled_at < 30.minutes.ago
  end
end

Lastly, scheduled_at is not my favorite because it's a unix timestamp. If this is accepted, I'd love the ok to go through a deprecation cycle (or go through a deprecation cycle before accepting this PR) to convert it to a DateTime like enqueued_at is handled.

Additional information

Related issues:

• Bugfix activejob improper serialization and deserialization of scheduled_at #32071
• Adding enque time tracking and logging #35238
• Recover precision when serializing Time, TimeWithZone and DateTime. #39698

Checklist

Before submitting the PR make sure the following are checked:

• This Pull Request is related to one change. Changes that are unrelated should be opened in separate PRs.
• Commit message has a detailed description of what changed and why. If this PR fixes a related issue include it in the commit message. Ex: [Fix #issue-number]
• Tests are added or updated if you fix a bug or add a feature.
• CHANGELOG files are updated for the changed libraries if there is a behavior change or additional feature. Minor bug fixes and documentation changes should not be included.

[zzak]

@bensheldon Could you rebase the changelog please? 🙏

[bensheldon]

@zzak will do!

Do you have any thoughts about my last note on changing scheduled_at to be a DateTime instead of a Unix timestamp? On second thought, it should probably be changed before it's exposed in the job 😬

[bensheldon]

@zzak I've rebased and tests are green.

fyi, I did slightly expand the scope of this PR to internally treat scheduled_at as a Time object instead of epoch timestamp/numeric (it should preserve existing behavior if someone is setting/reading job.scheduled_at directly instead of going through set(wait:, wait_until:)). I also tweaked the deserialization of enqueued_at to deserialize it back from an ISO8601 String to a Time object so that both scheduled_at and enqueued_at are treated similarly.

[zzak]

@bensheldon I'm suggesting this change because it's scope was limited in size and improves the API to be succinct with the ecosystem, but won't be backportable once 7.1 is released. My assumption here is that this also doesn't break any compatibility or require a deprecation cycle, so that makes it easier to review. By making this suggestion, however, I'm only asking someone from core (like RF) to double check those assumptions. If you have any other stuff that fits that criteria, I think now is the time.

[bensheldon]

Noting that there was a deprecation warning generated by the test helper:

• c919b47#r128527839

...and fixed here:

• 32eba97