Repository navigation
feat(drf): add automatic error tracking integration - #1036
Merged
Merged
Conversation
Contributor
posthog-python Compliance ReportDate: 2026-10-08T15:14:54.519202+00:00 ✅ All Tests Passed!121/121 tests passed Capture_V1 Tests✅ 95/95 tests passed View Details
Capture_Ai Tests✅ 5/5 tests passed View Details
Feature_Flags Tests✅ 17/17 tests passed View Details
Feature_Flags_Local_Evaluation Tests✅ 4/4 tests passed View Details
|
PR overviewAll previously flagged issues have been addressed. No open security concerns remain on this pull request. Security reviewNo open security issues remain on this pull request. Fixed/addressed: 1 · PR risk: 0/10 |
hpouillot
force-pushed
the
feat/drf-error-tracking
branch
from
October 8, 2026 10:22
481bc5f to
82e25e3
Compare
hpouillot
force-pushed
the
feat/drf-error-tracking
branch
from
October 8, 2026 10:32
82e25e3 to
686d569
Compare
ablaszkiewicz
approved these changes
Oct 8, 2026
hpouillot
force-pushed
the
feat/drf-error-tracking
branch
from
October 8, 2026 14:37
cd116a6 to
ca5a306
Compare
3 of 5 tasks
3 of 5 tasks
eli-r-ph
pushed a commit
that referenced
this pull request
Oct 10, 2026
* feat(drf): add automatic error tracking integration * fix(drf): align exception metadata with SDK spec * chore(drf): type exception capture metadata * fix(drf): honor Django request filtering * test(drf): describe context data as properties * feat(drf): support exception capture opt-out * chore(drf): update public API snapshot * fix(drf): align exception capture configuration * test(drf): preserve omitted setting default (cherry picked from commit 9baf8a5)
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
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.
💡 Motivation and Context
Django REST Framework converts handled exceptions into responses before Django middleware can observe them. This adds an idiomatic DRF
EXCEPTION_HANDLERthat captures handled 5xx errors while preserving DRF behavior and excluding expected 4xx responses by default.The integration is deliberately error-only: it imports DRF lazily, reuses the active Django request context, avoids duplicate captures, supports custom handlers and clients, and leaves unhandled exceptions for
PosthogContextMiddleware. Request properties remain owned by the Django context middleware rather than a second DRF-specificextra_propertiesAPI.Configuration follows the shared middleware contract:
capture_exceptions=True/Falseexplicitly overrides inherited configuration.POSTHOG_MW_CAPTURE_EXCEPTIONSis inherited.POSTHOG_MW_CAPTURE_EXCEPTIONS=Noneinheritsenable_exception_autocapturefrom the effective client.Truedefault.POSTHOG_DRF_CLIENT>POSTHOG_MW_CLIENT> global client.POSTHOG_MW_REQUEST_FILTERapplies to handled DRF errors as well as middleware-observed errors.💚 How did you test it?
uv run --no-sync pytest -q posthog/test/integrations/test_drf_integration.py --timeout=30— 24 passed, 4 subtests passeduv run --no-sync pytest -q posthog/test/integrations/test_drf_integration.py posthog/test/integrations/test_middleware.py --timeout=30— 55 passed, 4 subtests passeduv run --no-sync ruff format --check .uv run --no-sync ruff check .uv run --no-sync mypy --no-site-packages --config-file mypy.ini posthog/integrations/drf.py posthog/test/integrations/test_drf_integration.pyuv run --no-sync make public_api_checkuv run --no-sync python -W error -c "import posthog; import posthog.integrations.drf"📝 Checklist
If releasing new changes
sampo addto generate a changeset file🤖 Agent context
Autonomy: Human-driven (agent-assisted)
Implemented with pi using GPT-5.6 and Cockpit child sessions
0efe934b-1904-4c35-a722-0937ad74480eand1f64f01a-ab4f-4e7f-9ac6-e6f1d1c46ed7. The integration deliberately uses DRF's exception-handler hook rather than Django middleware because handled DRF exceptions no longer propagate to middleware. It captures 5xx responses by default, leaves 4xx capture opt-in, and never changes the delegated handler's response or exception behavior.Exception metadata conformance
Reviewed against the canonical
exception-event-metadataSDK specification. The consumed DRF response boundary emits levelerror, semantic mechanism typemiddleware, handled statetrue, and stable concrete sourcedjango_rest_framework.exception_handler; tests assert the complete typed metadata channel.