Query metric rollups using start_date derived from the first rollup #1265
Conversation
This resolves a time based sporadic failure. This means it works for many hours of the day but fails with specific ones. Previously, Time.zone is UTC, so Time.zone.today when run at August 15th at 12:05 AM UTC would return Thu, 15 Aug 2024. If we created the rollups using 1.hour.ago, the first one would be August 14th 11:05 PM. If we our rollups were on August 14th and we're looking for August 15th hourly rollups, we find nothing. This change ensures both the timestamp on the rollups and the start_date we query the rollups with come from the same time.
|
Cool I thought this was gonna involve some timecop shenanigans |
|
So is this technically a Rails 7 issue? That is you said Time.zone previously returns UTC, so does it not now? |
|
Checked commit jrafanie@cef1b13 with ruby 3.1.5, rubocop 1.56.3, haml-lint 0.51.0, and yamllint spec/requests/providers_spec.rb
|
Sorry, "previously" meant "before this commit". Our schedule runs for CI are at 12AM UTC so 1.hour.ago is the prior day. It looks like it's been failing, before rails 7, via scheduled but working on merges or manual runs because it's not in that 12-1AM UTC date range.
|
|
Backported to |
…_to_date_wrapping Query metric rollups using start_date derived from the first rollup (cherry picked from commit c46f881)
This resolves a time based sporadic failure. This means it works for many hours of the day but fails with specific ones.
Previously,
Time.zoneis UTC, soTime.zone.todaywhen run at August 15th at 12:05 AM UTC would returnThu, 15 Aug 2024.If we created the rollups using
1.hour.ago, the first one would be August 14th 11:05 PM.If we our rollups were on August 14th and we're looking for August 15th hourly rollups, we find nothing.
This change ensures both the timestamp on the rollups and the start_date we query the rollups with come from the same time.