Skip to content

Conversation

joseph-sentry
Copy link
Contributor

there's no index currently covering the testsuite, classname and name fields, and we don't want to create an index on those fields because names can be long, so we should group by test_id, because an index already exists

@joseph-sentry joseph-sentry requested a review from a team as a code owner August 8, 2025 16:45
@joseph-sentry joseph-sentry requested a review from a team August 8, 2025 16:45
Copy link

codecov bot commented Aug 8, 2025

Codecov Report

❌ Patch coverage is 95.74468% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 94.19%. Comparing base (75453d9) to head (bc20e36).
⚠️ Report is 1 commits behind head on main.

⚠️ Current head bc20e36 differs from pull request most recent head c5e613f

Please upload reports for the commit c5e613f to get more accurate results.
✅ All tests successful. No failed tests found.

Files with missing lines Patch % Lines
libs/shared/shared/django_apps/migration_utils.py 94.59% 1 Missing and 1 partial ⚠️
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #390   +/-   ##
=======================================
  Coverage   94.19%   94.19%           
=======================================
  Files        1261     1262    +1     
  Lines       46611    46646   +35     
  Branches     1491     1493    +2     
=======================================
+ Hits        43903    43936   +33     
- Misses       2404     2405    +1     
- Partials      304      305    +1     
Flag Coverage Δ
apiunit 96.17% <ø> (ø)
sharedintegration 40.04% <21.27%> (-0.12%) ⬇️
sharedunit 88.94% <95.74%> (+0.01%) ⬆️
workerintegration 61.28% <ø> (ø)
workerunit 90.70% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@codecov-notifications
Copy link

codecov-notifications bot commented Aug 8, 2025

Codecov Report

❌ Patch coverage is 95.74468% with 2 lines in your changes missing coverage. Please review.
✅ All tests successful. No failed tests found.

Files with missing lines Patch % Lines
libs/shared/shared/django_apps/migration_utils.py 94.59% 1 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

Copy link

codspeed-hq bot commented Aug 8, 2025

CodSpeed Performance Report

Merging #390 will not alter performance

Comparing joey/fix-cas (42ceb38) with main (4e970e9)1

Summary

✅ 9 untouched benchmarks

Footnotes

  1. No successful run was found on main (0e72252) during the generation of this report, so 4e970e9 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report.

@joseph-sentry joseph-sentry force-pushed the joey/fix-cas branch 3 times, most recently from bc20e36 to ed441ee Compare August 20, 2025 16:19
@joseph-sentry joseph-sentry added this pull request to the merge queue Aug 20, 2025
github-merge-queue bot pushed a commit that referenced this pull request Aug 20, 2025
* build: upgrade timescale version used in devenv

we were previously using timescaledb-ha:pg14-latest which hasn't been updated
in 2 years and is using a quite old version of timescale. So old in fact that it
predates timescale 2.13 which changed the default for CAs to being non-realtime

this broke a bunch of tests, which i fixed by manually calling the refresh
CA function in each test after creating measurements

I also took the liberty of switching from using django's timezone.datetime to
datetime with tzinfo UTC because those were showing up as errors in my linter

* fix: redefine new CAs to group by test_id

this commit also adds some utility functions for use in migrations for making
defining new CAs easier

i'm choosing to make the refresh CAs "risky" argument a required kwarg so that
it's obvious to the developer that they're either making the choice to have this
run on deploy or that they're going to have to run it themselves
we were previously using timescaledb-ha:pg14-latest which hasn't been updated
in 2 years and is using a quite old version of timescale. So old in fact that it
predates timescale 2.13 which changed the default for CAs to being non-realtime

this broke a bunch of tests, which i fixed by manually calling the refresh
CA function in each test after creating measurements

I also took the liberty of switching from using django's timezone.datetime to
datetime with tzinfo UTC because those were showing up as errors in my linter
@joseph-sentry joseph-sentry removed this pull request from the merge queue due to a manual request Aug 20, 2025
@joseph-sentry joseph-sentry disabled auto-merge August 20, 2025 16:58
@joseph-sentry joseph-sentry force-pushed the joey/fix-cas branch 2 times, most recently from 2da6cbb to 001f87e Compare August 20, 2025 19:05
this commit also adds some utility functions for use in migrations for making
defining new CAs easier

i'm choosing to make the refresh CAs "risky" argument a required kwarg so that
it's obvious to the developer that they're either making the choice to have this
run on deploy or that they're going to have to run it themselves
Comment on lines +198 to +204
forward_sql = f"""
CREATE MATERIALIZED VIEW {view_name}
WITH (
{",\n ".join(options)}
) AS
{select_sql_clean}{with_no_data_sql};
""".strip()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Potential bug: The create_continuous_aggregate function lacks IF NOT EXISTS, making migrations non-idempotent. Re-running a failed migration will cause a database error, halting the process and leaving the schema inconsistent.
  • Description: The create_continuous_aggregate function in migration_utils.py generates a CREATE MATERIALIZED VIEW SQL statement without the IF NOT EXISTS clause. While the migration drops views before recreating them, this is not robust. If the migration fails and is retried, the attempt to recreate an existing view will cause a relation "view_name" already exists error from PostgreSQL, halting the process. Because the migration is atomic = False, this failure can leave the database schema in a partially migrated, inconsistent state requiring manual intervention. This breaks the established pattern of idempotent migrations.

  • Suggested fix: Modify the create_continuous_aggregate function to include IF NOT EXISTS in the generated CREATE MATERIALIZED VIEW statement. This will make the migration idempotent and robust against retries, aligning with repository standards and preventing failures in operational scenarios like rollbacks or retries.
    severity: 0.72, confidence: 0.95

Did we get this right? 👍 / 👎 to inform future reviews.

@joseph-sentry joseph-sentry added this pull request to the merge queue Aug 20, 2025
Merged via the queue into main with commit c004881 Aug 20, 2025
81 of 83 checks passed
@joseph-sentry joseph-sentry deleted the joey/fix-cas branch August 20, 2025 20:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants