# Diagnose: infinite transaction names from URL parameters

## The symptom

Thousands of distinct transaction names like `GET /accounts/48291`, `GET /accounts/77123`, each with one event. Dashboards are useless, issue grouping fragments, and span quota burns on cardinality instead of signal.

## The cause

The transaction name includes raw URL parameters. Framework integrations normally parameterize routes (`GET /accounts/[id]`), but this breaks when: the route is not registered with the framework router (custom handlers, middleware), the integration does not recognize the framework, or you name transactions manually with the raw path.

## The fix

Name transactions by route pattern, not by URL:

```python
# instead of request.path
transaction_name = f"{request.method} {request.resolver_match.route}"
```

```js
Sentry.startSpan({ op: "http.server", name: "GET /accounts/[id]" }, () => { /* ... */ });
```

Put IDs and other high-cardinality values in attributes/tags instead, where they are searchable but do not create new groupings:

```js
Sentry.setAttribute("user.id", userId); // searchable, not a new transaction name
```

## Confirmation

In the transaction summary, sort by count of distinct names. A long tail of single-event names with the same shape is the fingerprint. After the fix, the tail collapses into a handful of route patterns.

## Verify

Distinct transaction names drop to roughly your route count, span quota usage falls, and dashboards aggregate meaningfully. In v11 stream mode this matters more, not less: spans are the unit now, and unnamed parameterized spans are just as fragmenting as transactions were.