Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(deps): Upgrade to Django 4.2 #18653

Merged
merged 52 commits into from
Apr 16, 2024
Merged

chore(deps): Upgrade to Django 4.2 #18653

merged 52 commits into from
Apr 16, 2024

Conversation

webjunkie
Copy link
Contributor

@webjunkie webjunkie commented Nov 15, 2023

Problem

Upgrade to latest Django version.

Changes

  • upgrading to Django 4.1 seems pretty straightforward, no major issues encountered, done in chore(deps): Upgrade Django 4.1 #20006
  • Django 4.2: Here Django started supporting psycopg==3.x which was recently added to the dependencies coincidentally. Most of the problems come from this. Otherwise also no blockers it seems.

Issues left:

  • pg_sleep(1) to make tests simulate slow DB is somehow not applied this issue vanished 🤷🏻
  • new duplicate key value violates unique constraint "posthog_organization_slug_key" errors come up this as well
  • SQL commenting has stopped working -> Postgres only, decided to remove it for now

How did you test this code?

webjunkie and others added 8 commits November 15, 2023 16:10
We need to be on >= 3.1.8

Locally there is an additional problem that somehow psycopg2
seemingly overshadows psycopg, making it appear that 3.1 works.

Had to install pip install "psycopg[binary,pool]==3.1.2" to
recreate the problem.
We use custom SQL that somehow doesn't get formatted in the right way
using server or client side cursors.
Copy link
Contributor

github-actions bot commented Nov 16, 2023

Size Change: -2.05 kB (0%)

Total Size: 2.01 MB

Filename Size Change
frontend/dist/toolbar.js 2.01 MB -2.05 kB (0%)

compressed-size-action

@webjunkie
Copy link
Contributor Author

@pauldambra We are green on Django 4.1 🚀
With Django 4.2 I have two issues left that so far don't make sense to me.

Copy link
Member

@pauldambra pauldambra left a comment

Choose a reason for hiding this comment

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

very quick scan, all looks good apart from the sql commenting.

I'll check it out and run it later on

@@ -48,7 +48,7 @@
"posthog_organization"."available_features"
FROM "posthog_organization"
WHERE "posthog_organization"."id" = '00000000-0000-0000-0000-000000000000'::uuid
LIMIT 21 /*controller='organization_resource_access-list',route='api/organizations/%28%3FP%3Cparent_lookup_organization_id%3E%5B%5E/.%5D%2B%29/resource_access/%3F%24'*/
Copy link
Member

Choose a reason for hiding this comment

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

I don't remember where they're set but it looks like the useful SQL commenting has stopped working

Copy link
Collaborator

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It seems Google gave this sqlcommenter to opentelemetry and it was not updated in a long time.

This might be where it ended up:
https://opentelemetry-python-contrib.readthedocs.io/en/latest/instrumentation/django/django.html#sqlcommenter

However, then there's this about supporting psycopg3, which I think might be the problem we have:
open-telemetry/opentelemetry-python-contrib#1751

How much do we need it anyways?

Copy link
Collaborator

Choose a reason for hiding this comment

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

oh dang it!

It's pretty useful for knowing where the request is coming from, specially when looking in, say, pganalyze for most popular sources of sql requests.

But, we do this manually for clickhouse ourselves, so wonder if there's an easy / small-scoped way to just do it ourselves

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've investigated further and also tried to use the middleware from opentelemetry that has some modifications as it seems.
Unfortunately, then immediately the following issue comes up 🥴
open-telemetry/opentelemetry-python-contrib#1554

It seems there are some differences between how the queries are handled and how the wrappers are executed. This would also explain why the pg_sleep wrapper has no effect anymore.

I'd say for now I'll make another PR just to upgrade to Django 4.1, where I had all CI green. Or does anyone have any suggestions?

Copy link
Member

Choose a reason for hiding this comment

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

Yep... a step on the road that works 🚀

@webjunkie webjunkie changed the title chore(deps): Upgrade Django chore(deps): Upgrade to Django 4.2 Nov 22, 2023
@webjunkie
Copy link
Contributor Author

I've created #18830 for Django 4.1 and would propose to leave this one here open to track issues for 4.2

@posthog-bot
Copy link
Contributor

This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in another week.

@posthog-bot
Copy link
Contributor

This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in another week.

@webjunkie
Copy link
Contributor Author

I merged master into this PR to update it and fixed some more issues, others meanwhile went away.
It's now looking ready.

One issue is that mypy shows errors in CI that I don't see locally. @pauldambra or @neilkakkar can someone check this locally as well and possibly just update the baseline?

@webjunkie webjunkie marked this pull request as ready for review April 3, 2024 14:28
@@ -3962,7 +3962,7 @@ def test_feature_flags_v3_consistent_flags(self, mock_is_connected):
# make sure caches are populated
response = self._post_decide()

with self.assertNumQueries(5, using="replica"), self.assertNumQueries(0, using="default"):
with self.assertNumQueries(9, using="replica"), self.assertNumQueries(0, using="default"):
Copy link
Collaborator

Choose a reason for hiding this comment

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

weird, how are there so many extra queries for flags, would you mind sharing the output here? I can look into this soon-ish as well

Copy link
Collaborator

Choose a reason for hiding this comment

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

oh its this

image

I'll do a once-over anyway to confirm they're legit

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah the increases should only be from this, the count changes do match that.

@@ -790,7 +790,8 @@ def get_all_feature_flags(
distinct_ids = [distinct_id, str(hash_key_override)]
query = """
WITH target_person_ids AS (
SELECT team_id, person_id FROM posthog_persondistinctid WHERE team_id = %(team_id)s AND distinct_id IN %(distinct_ids)s
SELECT team_id, person_id FROM posthog_persondistinctid WHERE team_id = %(team_id)s AND
distinct_id = ANY(%(distinct_ids)s)
Copy link
Collaborator

Choose a reason for hiding this comment

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

this is in preparation for psycopg3 update?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is the psycopg3 update as with Django 4.2 it's used actively.

Copy link
Collaborator

Choose a reason for hiding this comment

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

hmm, oh I see, I was looking at docs for psycopg3.2.0, https://www.psycopg.org/psycopg3/docs/basic/from_pg2.html#server-side-binding - this is what I expect will cause the pg_sleep() tests to fail because it sends a SET command with parameter binding

but we can leave this be for when its actually released :P

Also had a look at the psycopg2 usage still in the app, we can remove it in a follow up indeed, no need to do it right now. 👍

Copy link
Collaborator

@neilkakkar neilkakkar left a comment

Choose a reason for hiding this comment

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

Great job!

When we roll-out we should pause deploys and test this in dev / test in a canary deploy first!

@github-actions github-actions bot temporarily deployed to pr-chore/Django-4 April 8, 2024 08:58 Destroyed
@webjunkie webjunkie requested a review from benjackwhite April 8, 2024 09:17
@github-actions github-actions bot temporarily deployed to pr-chore/Django-4 April 8, 2024 09:38 Destroyed
@frankh frankh added canary and removed waiting Prevents stale-bot from marking the PR as stale. labels Apr 16, 2024
@github-actions github-actions bot temporarily deployed to pr-chore/Django-4 April 16, 2024 09:07 Destroyed
@frankh frankh merged commit dc0cf33 into master Apr 16, 2024
97 checks passed
@frankh frankh deleted the chore/Django-4 branch April 16, 2024 09:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants