revert(ci): undo unnecessary deepcopy in configure_split_db

The shallow copy was not the cause of dashboard test failures. The
TEST dict doesn't exist at copy time, so shallow vs deep is identical.
The real cause was missing order= on widget_1 and widget_2 fixtures.

Author: mchen-sentry

docs/investigations.md

@@ -0,0 +1,34 @@
+# Investigations
+
+## Dashboard Widget Ordering Failures Under xdist
+
+### The symptom
+
+5 out of 22 shards failed, all in `OrganizationDashboardDetailsPutTest`. Widget ID assertions mismatched:
+
+```
+FAILED test_remove_widget_and_add_new - assert 41 == 44
+FAILED test_reorder_widgets_has_no_effect - assert 27 == 25
+```
+
+### The wrong hypothesis
+
+Duplicate key errors in postgres logs (`sentry_email_email_key`, `sentry_dashboard_organization_title_uniq`) led to investigating whether xdist workers shared the same Postgres database. Investigated `configure_split_db()` shallow copy, pytest-django's `_set_suffix_to_test_databases`, and `TEST.NAME` propagation. All turned out to be irrelevant — the duplicate key errors were from `initialize_app()` startup, not from test execution.
+
+### The misleading grep
+
+Searching for `order=` in the test file found lines 70 and 80 with `order=0` and `order=1`. These were assumed to be on `DashboardWidget` objects. They were actually on `DashboardWidgetQuery` objects (queries *within* a widget) — a different model created in the same `setUp` method with visually identical indentation.
+
+### The actual root cause
+
+`widget_1` and `widget_2` in `OrganizationDashboardDetailsTestCase.setUp()` were created without `order=`. `DashboardWidget.order` is `BoundedPositiveIntegerField(null=True)`, so both had `order=NULL`. `get_widgets()` uses `ORDER BY (order, id)`. PostgreSQL's ordering of NULL values is nondeterministic (heap scan order), so widget ordering varied depending on prior test activity within the worker session.
+
+Under xdist with `--reuse-db` and `PYTHONHASHSEED=0`, the test distribution across shards is deterministic. The same 5 shards always got this test file with enough prior DB activity to scramble the NULL ordering. Without xdist, the test happened to pass due to a lucky heap layout.
+
+### The fix
+
+Added `order=0` to `widget_1` and `order=1` to `widget_2` in the parent `setUp`. Combined with the earlier fix of `order=2` and `order=3` on `widget_3` and `widget_4` in the child `setUp`, all widgets now have deterministic ordering.
+
+### Lesson
+
+Add diagnostic output early. The debug print (`for w in widgets: print(f"id={w.id} order={w.order}")`) immediately showed `Widget 1 order=None` and resolved the issue in one iteration.

docs/notes.md

@@ -33,12 +33,6 @@ Verified empirically: `socket.setdefaulttimeout(5)` → listening socket `.getti
 
 This is a subtle interaction: `pytest-rerunfailures` assumes sockets block indefinitely, but Sentry's global timeout silently changes that contract on accepted connections only.
 
-## configure_split_db shallow copy bug
-
-`configure_split_db()` used `.copy()` (shallow) to create `control` and `secondary` from `default`. The `TEST` dict inside each was the **same Python object**. When pytest-django's `_set_suffix_to_test_databases` iterated databases and set `TEST.NAME` for each, the last write overwrote all three. All workers ended up using the same Postgres database instead of per-worker isolation (`test_region_gw0`, `test_control_gw0`, etc.). Fixed with `copy.deepcopy()`.
-
-This bug was latent on master (no xdist, no TEST.NAME collision) and only manifested under xdist where per-worker DB names are required.
-
 ## Why hash-based sharding beats algorithmic LPT
 
 With 17+ shards and ~32K tests, the law of large numbers gives hash-based (`sha256(nodeid) % N`) sharding good-enough balance (~90-130s spread). LPT algorithms failed because:

docs/tiered-xdist-changes.md

@@ -93,13 +93,7 @@ Normal `--reruns` is unaffected — each worker retries failed tests locally via
 
 The `calculate-shards` job now has a fast path: when selective testing isn't active (push to master/branch), it outputs static defaults (22 shards) without checkout, setup-sentry, or `pytest --collect-only`. Saves ~3 min on the critical path. When selective testing IS active (PR), the full collection pipeline still runs to compute the right shard count.
 
-### 2g. Fix shared TEST dict in configure_split_db
-
-**Modified:** `src/sentry/testutils/pytest/sentry.py` (`configure_split_db`)
-
-Changed `.copy()` to `copy.deepcopy()` when creating `control` and `secondary` database configs. The shallow copy caused all three databases to share the same `TEST` dict object. When pytest-django's xdist suffix fixture set `TEST.NAME` for each database, the last write won — all three databases got the same test DB name. Workers shared a single Postgres database instead of getting isolated `test_region_gw0`, `test_control_gw0`, etc.
-
-### 2h. Snowflake test fix
+### 2g. Snowflake test fix
 
 **Modified:** `tests/sentry/utils/test_snowflake.py`
 

src/sentry/testutils/pytest/sentry.py

@@ -42,14 +42,12 @@ def configure_split_db() -> None:
     if already_configured or _use_monolith_dbs():
         return
 
-    import copy
-
-    settings.DATABASES["control"] = copy.deepcopy(settings.DATABASES["default"])
+    settings.DATABASES["control"] = settings.DATABASES["default"].copy()
     settings.DATABASES["control"]["NAME"] = "control"
 
     settings.DATABASES["default"]["NAME"] = "region"
 
-    settings.DATABASES["secondary"] = copy.deepcopy(settings.DATABASES["default"])
+    settings.DATABASES["secondary"] = settings.DATABASES["default"].copy()
     settings.DATABASES["secondary"]["NAME"] = "secondary"
 
     settings.DATABASE_ROUTERS = ("sentry.db.router.TestSiloMultiDatabaseRouter",)