fix(data-imports): keep known-transient S3 blips out of error tracking in get_delta_table - #74653
Merged
trunk-io[bot] merged 1 commit intoJul 29, 2026
Conversation
…g in get_delta_table get_delta_table() unconditionally reported every exception from the is_deltatable check and the DeltaTable() open to error tracking, even ones matching the existing is_transient_object_store_error classifier (e.g. an S3 LIST request timing out). Those are self-recovering network blips that Temporal already retries automatically, so reporting them is just noise. Skip capture_exception (log a warning instead) when the error matches the known-transient pattern, in both except blocks; the exception is still re-raised either way so retry behavior is unchanged. Generated-By: PostHog Code Task-Id: e7f0cc1d-199a-486f-b740-0163f18a42e7
|
😎 Merged successfully - details. |
Contributor
|
Hey @Gilbert09! 👋 It looks like your git author email on this PR isn't your
You can fix it for this repo with: git config user.email "you@posthog.com"Or set it globally with |
![stamphog[bot]](https://avatars.githubusercontent.com/in/3000332?s=60&v=4){kind=small}
There was a problem hiding this comment.
Small, contained fix that suppresses error-tracking noise for known-transient S3 errors while always re-raising (no change to retry behavior); no risky territory touched, author owns the code with strong familiarity, and tests cover both branches.
- Author wrote 83% of the modified lines and has 0 merged PRs in these paths (familiarity STRONG).
- 👍 on the PR from hex-security-app[bot].
Gate mechanics and policy version
| Gate | Result | |
|---|---|---|
| prerequisites | ✓ | all clear |
| deny-list | ✓ | no deny categories matched |
| size | ✓ | 15L, 1F substantive, 46L/2F incl. docs/generated/snapshots — within ceiling |
| tier | ✓ | T1-agent / T1b-small (46L, 2F, single-area, fix) |
| stamphog 2.0.0b3 | .stamphog/policy.yml @ 1bad8d1 · reviewed head 0357872 |
Contributor
|
/trunk merge |
trunk-io
Bot
deleted the
posthog-code/fix-transient-s3-noise-get-delta-table
branch
July 29, 2026 13:39
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Problem
Error tracking surfaced an
OSError: Generic S3 error ... operation timed outfromDeltaTableHelper.get_delta_table(), raised while callingdeltalake.DeltaTable.is_deltatable(...).This is the same class of self-recovering S3 blip already documented by
TRANSIENT_OBJECT_STORE_ERRORS/is_transient_object_store_errorindelta_table_helper.py— a transient network hiccup on an S3 LIST request, not a customer credential problem or a bug in our code. It's already retryable today: nothing here is in any source'sNonRetryableErrors, and Temporal's default activity retry policy applies, so the sync itself was never at risk. The gap is purely reporting noise:get_delta_table()'s two except blocks (around theis_deltatableexistence check and theDeltaTable()open) callcapture_exceptionunconditionally, without ever consulting the classifier that already exists in the same file for exactly this error family.Changes
DeltaTableHelper._capture_unless_transient, which callscapture_exceptiononly when the error is not a known-transient object-store blip (falls back to a warning log otherwise). The exception is always re-raised regardless, so Temporal's retry behavior is unchanged.get_delta_table()through it.How did you test this code?
TestGetDeltaTableUnrecoverableErrorsintest_delta_table_helper.py:is_deltatablecapture test to use a genuinely non-transient error (Access Denied), since its previous example text happened to match the transient-error substring pattern.test_is_deltatable_transient_error_is_not_captured_but_still_reraised, reproducing the exact production error text — assertscapture_exceptionis not called, a warning is logged, and the exception still propagates (so Temporal still retries).ensure_bucket_existsagainst, same pre-existing constraint as the rest of this test file); both new/updated cases pass with the expected behavior.uv run mypy --cache-fine-grained .(repo-wide) — clean.ruff check --fix/ruff format— clean.Automatic notifications
Docs update
N/A — internal error-classification change, no user-facing or API behavior change.
🤖 Agent context
Autonomy: Fully autonomous
Triaged directly from the linked error-tracking issue via PostHog's error-tracking MCP tools (
query-error-tracking-issue,query-error-tracking-issue-events), which surfaced the stack trace pinning the failure toget_delta_table'sis_deltatablecall. Traced the call path and confirmed via a research subagent that Temporal's retry policy already treats thisOSErroras retryable — the actual gap was reporting noise, not retry correctness.Checked for duplicate open PRs by exception type, message phrase, and module path, and scanned the maintainer's own open PR queue. Found several related-but-non-overlapping PRs touching transient S3 handling elsewhere in the same file/module (e.g. #74388 for the
_handle_import_errorfallback path, #69306 and #74630 for vacuum/compact maintenance, #73395 for query-folder cleanup) — none of them touchget_delta_table's owncapture_exceptioncalls, which is the gap this PR closes.Invoked
/writing-testsbefore adding the regression tests.