Verify spans are available for SQL transactions (converted to project)

[mrduncan]

This issue has been converted to a project SQL Transactions Spans [Symfony]

---

In HTTP Requests within SQL Transactions we would like to detect when HTTP client requests are being made during a SQL transaction however to do this correctly, we need to verify that we have spans available from each backend SDK for database transactions. Some SDKs are known to not send this information (ex: Django) so we'd like to audit where it is/isn't available and get it added where it's not available.

These are generally BEGIN, COMMIT, and ROLLBACK however if we are doing any special casing in SDKs there are nuances depending on the SQL dialect (ex: MySQL supports START TRANSACTION in addition to BEGIN). The linked milestone above has more details in the FAQ section.

Creating these tickets as duplicates for each backend SDK team, original Slack thread in #discuss-sdks: https://sentry.slack.com/archives/CA2V2LBDL/p1745252678799129

[Litarnus]

@mrduncan This is how it currently looks in Symfony.

Note that even though it says BEGIN TRANSACTION and COMMIT, the ops are db.sql.transaction.begin and db.sql.transaction.commit respectively

[mrduncan]

@cleptric I'm realizing that we have two distinct ways to send these between this and getsentry/sentry-laravel#990.

I'm a bit torn on the "correct" approach though:

• db.sql.transaction.{begin,commit} is nice since these do require a server round-trip and these expose that information as spans as one would naturally expect
• db.sql.transaction is nice since it does a much better job of visually showing what the transaction covers and the transaction duration

[cleptric]

@mrduncan which "style" does our detector code currently understands? Changing span ops got a bit controversial as of late, as you can create alerts, queries and dashboards on theses values, hence any changes likely justify them being included on a new major SDK version.

[mrduncan]

We don't do any detection on these specifically yet so it's easy enough for us to adapt in either direction, I would just prefer we unify around one style as much as possible