fix(data-imports): retry transient DB connection drops on two import reads

[posthog]

Problem

• A ~2 minute pooler blip threw a burst of uncaught OperationalErrors out of the data warehouse import path, straight into error tracking for the data imports team.
• Two reads of PostHog's own Postgres go through database_sync_to_async_pool with no retry and no error classification: CDPProducer.get_dot_notated_table_name() and update_last_synced_at().
• The worse tail risk is misclassification. A raw OperationalError from our DB stringifies the same way a customer's misconfigured source host does, so a source's get_non_retryable_errors can match it and permanently stop a healthy sync.
• The guard already exists one method over: should_produce_table() catches OperationalError and re-raises PostHogInternalDatabaseError for exactly this reason. get_dot_notated_table_name() is its prerequisite and never got it.

Changes

Call site	Before	After
cdp_producer.get_dot_notated_table_name	raw ORM read	aretry_on_db_connection_drop + re-raise as PostHogInternalDatabaseError
pipeline_sync.update_last_synced_at	raw ORM read/write	aretry_on_db_connection_drop
cdp_producer.should_produce_table	already guarded	unchanged

• Retry uses the existing helper in posthog/temporal/common/utils.py (evict the stale connection, retry once), same as repartition_controller.py:80. Nothing hand-rolled.
• A second consecutive failure still propagates, but now as PostHogInternalDatabaseError, clear of the substrings source classification keys on.

Note

update_last_synced_at retries a small read-then-save, which is idempotent, so the retry is safe there.

How did you test this code?

Added two tests in test_cdp_producer.py, mirroring the existing should_produce_table connection-failure test:

• test_get_dot_notated_table_name_retries_once_on_connection_drop – the first ORM read raises, the second succeeds, and the resolved name still comes back. Catches removal of the retry wrapper, which no existing test covers.
• test_get_dot_notated_table_name_database_failure_stays_retryable – parameterized over OperationalError and InterfaceError; asserts a persistent failure surfaces as PostHogInternalDatabaseError whose message matches none of PostgresSource().get_non_retryable_errors(). This is the misclassification regression.

What I could and could not run

• ruff check / ruff format – clean
• tach check --dependencies --interfaces – clean
• mypy --cache-fine-grained on both changed modules – clean
• The new tests need Postgres (django_db(transaction=True)) and no database was available in this environment, so I did not execute them. No manual testing was done.

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

Docs update

N/A, internal retry and error-classification change with no user-facing behavior change.

🤖 Agent context

Autonomy: Fully autonomous

I (Claude) worked from an inbox report on the error burst. I checked for competing work first: #72062 added the sync retry_on_db_connection_drop helper and applied it to mark_initial_sync_complete, and #73386 broadens transient classification in pre-write maintenance. Neither touches these two call sites, so this is additive on top of the same pattern.

I considered also wrapping should_produce_table's _check() in the retry, but kept the change to the two unguarded reads the report identified rather than widening scope. I invoked /writing-tests and /writing-code-comments.

---

Created with PostHog Desktop from this inbox report.

[trunk-io]

Merging to master in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here