[BUG] Elastic APM — EF Core SQL Spans Missing

[bftelman]

AddAllElasticApm() is documented as the recommended replacement for UseAllElasticApm(), but its DI-based lazy registration runs after app.Run(). Apps that use DbContext in startup code (before app.Run()) will permanently miss the EF Core DiagnosticListener because DiagnosticListener.AllListeners does not replay past emissions.

The bug - current behavior:

// AddElasticApm registers subscribers via a hosted service
services.AddSingleton(sp =>
{
Agent.Setup(...);
Agent.Instance.Subscribe(subscribers); // runs at app.Run() - too late
return Agent.Instance;
});
services.AddHostedService(); // only purpose: resolve IApmAgent above

// By the time ApmService starts at app.Run(),
// startup code has already triggered the EF Core DiagnosticListener.

Folowing is a code snippet from project i am working on:
app.Services.GetService().GetUserById(Guid.Empty); // ← first DbContext use
// → "Microsoft.EntityFrameworkCore" DiagnosticListener published to AllListeners
// → EfCoreDiagnosticsSubscriber subscribes 100ms later → misses it permanently
app.Run();

---

Proposed fix - subscribe via IStartupFilter instead:

// IStartupFilter runs synchronously during middleware pipeline construction,
// before any startup code executes DbContext operations
internal class ApmStartupFilter(IApmAgent agent, IDiagnosticsSubscriber[] subscribers)
: IStartupFilter
{
public Action Configure(Action next)
=> app =>
{
agent.Subscribe(subscribers); // ← fires before GetUserById, Synchronise, etc.
next(app);
};
}

// Registration:
services.AddSingleton(sp =>
new ApmStartupFilter(sp.GetRequiredService(), subscribers));

This matches the timing of UseAllElasticApm (synchronous, during pipeline build) without requiring the deprecated middleware API.

[stevejgordon]

@bftelman I don't think this would cause the agent to "permanently miss the EF Core" spans. Any EF operations which occur after startup should still be captured because the Subscribe mechanism replays a new subscriber against any existing listener. Have you observed no spans later in the application when EF queries run? If so, can you review the debug logs and provide a self-contained minimal repro we can investigate? I tested on a sample here and everything looks fine.

To force early agent initialisation, you should be able to do something like this:

var app = builder.Build();

// This is important as it initialises the agent is its subscriptions before EF usage
_ = app.Services.GetRequiredService<IApmAgent>();

// We also need to create a manual transaction so EF spans are captured
var transaction = Agent.Tracer.StartTransaction("Startup", ApiConstants.TypeApp);

try
{
    // EF Core calls here will produce spans within the "Startup" transaction
    using var scope = app.Services.CreateScope();
    var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
    var users = db.Users.ToList();
}
catch (Exception e)
{
    transaction.CaptureException(e);
    throw;
}
finally
{
    transaction.End();
}

app.Run();

After forcing the initialisation of the agent by resolving it, you also need a transaction running for EF instrumentation spans to be captured. This example uses the public API to do that.

[stevejgordon]

@bftelman - I just wanted to follow up and see if this helped?