Feature request: optional dropping of Laravel `laravel.event.handle` spans (high volume / noise)

[luancsl]

Describe the feature you'd like

Summary

Laravel traces can contain a very large number of laravel.event.handle spans (one per Illuminate\Events\Dispatcher::dispatch / fire call), including Eloquent model lifecycle events (eloquent.*), cache hits, and other framework events. These spans are often extremely short (microseconds) and clutter flame graphs without adding much signal for many users.

Problem

• Flame graphs can become hard to read (thousands of spans per trace).
• High cardinality and cost (storage/ingestion) for little diagnostic value in typical workloads.

Proposed solution

Add an opt-in/opt-out configuration flag (e.g. DD_TRACE_LARAVEL_DROP_EVENT_SPANS) that, when enabled, schedules dropping of laravel.event.handle spans (e.g. via DDTrace\try_drop_span on span close) so they are not sent to the backend.

Note: Implementation details (default true vs false, exact env name, interaction with try_drop_span when children exist) are open for discussion with maintainers.

Configuration (proposal)

Env	Type	Purpose
DD_TRACE_LARAVEL_DROP_EVENT_SPANS	bool	When true, drop laravel.event.handle spans (after close / per tracer semantics).

Trade-offs / considerations

• Pros: Cleaner traces, less noise, better UX in APM.
• Cons: Users who rely on laravel.event.handle for debugging lose visibility unless they disable the option.
• Default: Should be chosen conservatively (likely false for backward compatibility, unless product agrees otherwise).

Alternatives considered

• Filtering only Eloquent-prefixed event resources (eloquent.*) — narrower.
• Dropping only “leaf” event spans (no child spans) — more complex; still debated.

Related

• Laravel integration instruments Illuminate\Events\Dispatcher (dispatch / fire) in LaravelIntegration.php.

---

Would the maintainers be open to a PR for this? If yes, I’m happy to align on naming, default value, tests, and docs before implementation.

Is your feature request related to a problem?

No response

Describe alternatives you've considered

No response

Additional context

No response