feat: add Django Ninja exception recording to instrument_django()

[Br1an67]

Summary

Integrates Django Ninja exception recording into instrument_django() via a new instrument_ninja=True parameter (enabled by default).

Django Ninja catches exceptions before they propagate to Django's middleware, preventing OpenTelemetry's Django instrumentation from recording them. This patch hooks NinjaAPI.on_exception at the class level to record exceptions on the current span.

Closes #1742

Changes

• logfire/_internal/integrations/django.py: Added _instrument_django_ninja() which patches NinjaAPI.on_exception on the class. Silently skipped if django-ninja is not installed. Uses _LOGFIRE_INSTRUMENTED constant for double-instrumentation guard.
• logfire/_internal/main.py: Added instrument_ninja: bool = True parameter to instrument_django(). Removed separate instrument_django_ninja() method.
• Type stubs: Updated instrument_django signature with instrument_ninja parameter.
• Tests: 7 tests covering good route, handled errors, unhandled errors, double-instrumentation guard, and head_sample_rate=0 branches.
• Removed django-ninja optional extra (users instrumenting Django Ninja are expected to have it installed).

Key Design Decisions

• Patches at the class level so it works without arguments (for logfire run)
• Correctly sets escaped=True when Django Ninja re-raises unhandled exceptions, escaped=False when handled
• No separate API method — integrated into the existing instrument_django() flow

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[alexmojaki]

1. We need this to work without requiring passing arguments, for the logfire run command. If you think it's useful to be able to specify api instead of instrumenting everything globally, then that can be an option, but it's not essential. In this case, that means patching NinjaAPI.on_exception on the class.
2. Please make this part of instrument_django instead of adding another method and requiring users to call both.
3. Please mention this in the django docs.

[alexmojaki]

move to top

[alexmojaki]

use constant for consistency

[alexmojaki]

test these branches by setting the head sample rate to 0

[alexmojaki]

this extra isn't needed, we assume that users instrumenting a package have that package. same goes for catching the import error.

[Br1an67]

Thanks for the detailed review! I've restructured the PR completely based on your feedback:

1. No separate method — ninja patching is now part of instrument_django(instrument_ninja=True) (enabled by default)
2. Class-level patching — patches NinjaAPI.on_exception on the class, works without arguments for logfire run
3. Imports at top level — get_current_span imported at module top
4. _LOGFIRE_INSTRUMENTED constant used for double-instrumentation guard
5. head_sample_rate=0 tests added to verify is_recording() branches
6. Removed django-ninja extra and ImportError catch — silently skips if not installed

Deleted the separate instrument_django_ninja() method, its API stubs, and public exports entirely.

[devin-ai-integration]

Devin Review found 2 new potential issues.

View 8 additional findings in Devin Review.

[devin-ai-integration]

🟡 Wrong exception recorded when a Django Ninja exception handler itself raises

In patched_on_exception, the except Exception block always records the original exc parameter, but the exception that actually escapes may be different.

Root Cause

Django Ninja's on_exception (ninja/main.py) can raise a different exception than exc when a registered exception handler itself fails:

def on_exception(self, request, exc):
    handler = self._lookup_exception_handler(exc)
    if handler is None:
        raise exc          # same as exc — OK
    return handler(request, exc)  # handler could raise something else!

In the patched version at logfire/_internal/integrations/django.py:68-70:

except Exception:
    if span.is_recording():
        span.record_exception(exc, escaped=True)   # always records exc
    raise                                           # re-raises the *actual* exception

If handler(request, exc) raises a ValueError, the code records the original exc (e.g. HttpError) on the span with escaped=True, but the raise propagates the ValueError. The trace shows the wrong exception type and message.

The fix is to capture and record the actually-raised exception:

except Exception as raised_exc:
    if span.is_recording():
        span.record_exception(raised_exc, escaped=True)
    raise

Impact: Users inspecting spans would see a misleading exception type/message that doesn't match the actual error that propagated.

Suggested change

	except Exception:
	if span.is_recording():
	span.record_exception(exc, escaped=True)
	except Exception as raised_exc:
	if span.is_recording():
	span.record_exception(raised_exc, escaped=True)

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🚩 Behavioral change: instrument_ninja=True by default for all existing instrument_django() callers

The instrument_ninja parameter defaults to True at logfire/_internal/main.py:1606. This means all existing users calling logfire.instrument_django() will now automatically get Django Ninja's NinjaAPI.on_exception monkey-patched at the class level if django-ninja is installed. While the ImportError is silently caught at logfire/_internal/integrations/django.py:56, users who DO have Django Ninja installed but don't use it with Logfire may be surprised by the class-level patching. This is likely intentional (as stated in the PR description and docstring), but worth a reviewer confirming this opt-out vs opt-in decision.

---

Was this helpful? React with 👍 or 👎 to provide feedback.