Set created_at for jobs based on table row #10
Conversation
| @@ -157,6 +100,7 @@ | |||
| run_at: nil, | |||
| queue: nil, | |||
| wrapped: nil, | |||
| created_at: be_within(10**-6).of(job.created_at), | |||
There was a problem hiding this comment.
heh i guess we dont have any time helpers do we?
There was a problem hiding this comment.
Not that I'm aware of. Are there common ones you'd suggest?
There was a problem hiding this comment.
timecop for freezing time, but im totally cool with this in lieu of adding another dev dependency
There was a problem hiding this comment.
Ah, in this case it's not a freezing issue, it's a rounding/precision issue for the same value. I've run into this before that you'll get slightly more precision on Linux vs OSX, so things that match exactly locally will differ in CI.
Update: specifically a precision issue after database round-tripping
There was a problem hiding this comment.
oh sorry! wasnt looking close enough. we have a custom match_time matcher and with_database_precision helper in ez-rails takes care of precision issues of time objects in mem and time from the db
There was a problem hiding this comment.
I'm going to leave this as-is for now, but maybe eventually we extract that to ezcater_matchers.
There was a problem hiding this comment.
agreed! getting off track now but we should audit all the custom matchers in ez-rails at some point and decide what to move to ezcater_matchers
|
I just didn't include it in the first pass since it wasn't required. |
What did we change?
Pass in the
created_atvalue from the jobs table when enqueueing Sidekiq jobs.Remove unnecessary code for manually publishing a single job.
Why are we doing this?
Sidekiq allows this value be passed in or defaults it to the current time if unset.
How was it tested?