Added Sentry.Samples.OpenTelemetry.MongoDB

[jamescrosswell]

Demonstrates how to instrument MongoDB using OTLP. Spans captured this way are automatically scrubbed and available in Sentry's Queries dashboard.

I'm not sure if we want to push this in our core repo - technically it's not demonstrating anything Sentry has built (except the OTLP integration - but there are tens of thousands of different ways that can be used). On the other hand, MongoDB is extremely popular and wiring all of this up might not be entirely obvious to SDK users.

Other options (not mutually exclusive):

• Put it in https://github.com/sentry-demos
• Write up a short blog post (good opportunity to talk about the new OTLP integration and couple it with a valuable use case)

Note

It would be possible to make Mongo DB instrumentation available even to SDK customers who are not using our OTLP integration... basically we'd have to build an integration that includes a custom ActivityListener that listens to the MongoDB events (similar to what we did to support Microsoft.Extensions.AI.Abstractions) and then translate those into Sentry spans. I'm not sure we want to do that though - it's another thing to maintain. I guess there would have to be clear reasons why customers would want MongoDB instumentation but not be able to or not want to use our OTLP integration. Currently we don't have anyone in that situation talking to us so it may be an imaginary problem to solve.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.18%. Comparing base (bfcb8a9) to head (ce26817).
⚠️ Report is 10 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5335      +/-   ##
==========================================
+ Coverage   74.15%   74.18%   +0.02%     
==========================================
  Files         508      508              
  Lines       18353    18373      +20     
  Branches     3586     3595       +9     
==========================================
+ Hits        13610    13630      +20     
  Misses       3870     3870              
  Partials      873      873              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 9403424. Configure here.}

[cursor]

Wrong exception type caught

Medium Severity

When MongoDB is unreachable, the driver throws a MongoConnectionException (or another MongoException) after ServerSelectionTimeout, not TimeoutException. The handler meant to print the README Docker hint never runs, so users see an unhandled exception instead of the friendly message.

 

^{Reviewed by Cursor Bugbot for commit 9403424. Configure here.}

[jamescrosswell]

This is a false positive — catch (TimeoutException) is correct here.

When the server can't be selected within ServerSelectionTimeout, the driver propagates a plain System.TimeoutException, not a MongoException. The MongoConnectionException mentioned above is real, but it's only embedded as the HeartbeatException inside the cluster-state diagnostics of the timeout message — it's the inner reason a server couldn't be selected, not the type that reaches the caller.

Source: Cluster.HandleServerSelectionException (driver v3.9.0) wraps and throws a new TimeoutException(...) — that's the message with the embedded MongoConnectionException that this finding was pattern-matching on.

Verified empirically with driver 3.9.0 and this sample's exact settings (ServerSelectionTimeout = 3s), catching Exception and printing the runtime type:

Scenario	Thrown type	is TimeoutException	is MongoException
Connection refused (closed port)	System.TimeoutException	✅	❌
Unreachable host	System.TimeoutException	✅	❌

Broadening the catch would actually be a regression: the intent is to show the "Is MongoDB running?" hint only for the connection-timeout case. A genuine MongoException (auth failure, a real query bug, etc.) should surface as itself rather than be masked behind a misleading "is MongoDB running?" message.

[dingsdax]

Does it when going through OTLP endpoint? I am not sure about that 🤔?

[jamescrosswell]

Hm, so it turns out it kind of does but not really. It does for the purposes of grouping queries in the dashboard but ultimately the raw queries are retained for the Trace/Span samples... so from a PII perspective it doesn't.

I've corrected in ce26817 - also added a custom OTEL SpanProcessor to demonstrate how SDK users can implement scrubbing client side.

The blog post will need updating as well - once this PR is merged, I can link to the sample in the repo from the blog post.

[dingsdax]

please have a final look at the .NET content from getsentry/sentry-docs#18441 I'm quite confident it's OK, but still 🙏, will need to check the last Symfony error and then it's good to go 🚀