New Relic APM: Stale Transaction Trace Data Persists After Deletion

Short answer: the stale trace you're seeing is almost certainly coming from the UI-side cache, not the database. The deletion worked; the cache just hasn't caught up. There is no user-facing way to flush a single trace from that cache, and the cache key design is not something you can change yourself.

Why time-based eviction appears to "fail"

The likely explanation is a sliding (access-refreshed) expiration rather than a fixed TTL. With sliding expiration, every time someone opens the trace in the UI, the cache entry's timer resets. A trace that gets viewed repeatedly—say, one linked in an incident channel or a dashboard—can stay cached long past its nominal lifetime, even after the underlying record is removed by retention or manual deletion. Under low traffic the same cache would appear to evict correctly, which makes the behavior look inconsistent.

This is the likely explanation, not a confirmed one. What is confirmed is the second problem: the cache key is built from transaction name plus timestamp only, without the trace ID. Two traces with the same name and timestamp collide on one key, so the UI can serve an older trace's payload for a newer request. That collision can make staleness look permanent even when eviction is working.

Can you change the cache key to include the trace ID?

No—not from your side. The key design lives in New Relic's product code, so including the trace ID would require a product release. If it were changed, the trade-offs would be predictable: key cardinality goes up, collision-driven staleness largely disappears, but cache hit ratio drops and memory usage grows because near-identical entries no longer share a slot. The eviction algorithm itself would stay time-based, so sliding-TTL staleness could still occur. Given that New Relic has acknowledged a pending fix with no date, treat this as their problem to ship, not something to engineer around in your account.

Programmatic eviction options

There is no API, NerdGraph mutation, or UI control to invalidate a specific trace or the whole trace cache. In practice the cache clears when:

• the TTL finally expires (i.e., access stops long enough for the timer to run out),
• the UI service is restarted or a product update invalidates the cache,
• your local view changes—clearing browser cache/local storage or using a private window rules out any client-side component.

How to verify which case you're in

1. Delete the trace, then view the UI from a clean browser session. If it's gone, the persistence was client-side.
2. If it persists, stop accessing it entirely and re-check after the documented cache TTL. Disappearance on schedule means eviction works and sliding expiration was the culprit.
3. If it survives well past the TTL, you're likely seeing a key collision or a genuine eviction bug—collect the trace ID, timestamps, and screenshots and open a New Relic support case referencing the known pending fix.

One detail that would sharpen this: the configured TTL for the trace cache in your account. If observed persistence exceeds that TTL under zero access, escalation to support is the right move rather than further local debugging.