fix(eventstore): Use more correct start date for eventstore #67070
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Clickhouse behaves oddly when the normal epoch is used for dates: ClickHouse/ClickHouse#9335 (comment) This was working before by coincedence: an obsolete piece of code (query splitters) in Snuba was clamping the date to a non-epoch value. When the query splitters were removed, this started breaking. Instead of simply asking for "all time" use a date that aligns with how our data is actually stored. This is also not a new issue, see #30912
github-actions
bot
added
the
Scope: Backend
volokluev
reviewed
Mar 15, 2024
| prev_filter.start = datetime.fromtimestamp(0) | ||
|
|
||
| # We only store 90 days of data, add a few extra days just in case | ||
| prev_filter.start = event.datetime - timedelta(days=100) |
There was a problem hiding this comment.
this is quite a few days, I don't think I quite get why we need to go back so far
There was a problem hiding this comment.
Neither do I, but I didn't want to break any existing assumptions. The goal was to have this feature continue to work the way it was before.
volokluev
approved these changes
Mar 15, 2024
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #67070 +/- ##
=======================================
Coverage 84.27% 84.27%
=======================================
Files 5307 5307
Lines 237285 237301 +16
Branches 41054 41053 -1
=======================================
+ Hits 199973 199987 +14
- Misses 37094 37096 +2
Partials 218 218
|
JonasBa
pushed a commit
that referenced
this pull request
Mar 17, 2024
Clickhouse behaves oddly when the normal epoch is used for dates: ClickHouse/ClickHouse#9335 (comment) This was working before by coincedence: an obsolete piece of code (query splitters) in Snuba was clamping the date to a non-epoch value. When the query splitters were removed, this started breaking. Instead of simply asking for "all time" use a date that aligns with how our data is actually stored. This is also not a new issue, see #30912
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Clickhouse behaves oddly when the normal epoch is used for dates:
ClickHouse/ClickHouse#9335 (comment)
This was working before by coincedence: an obsolete piece of code (query
splitters) in Snuba was clamping the date to a non-epoch value. When the query
splitters were removed, this started breaking.
Instead of simply asking for "all time" use a date that aligns with how our
data is actually stored.
This is also not a new issue, see #30912