Flare Debug Sender Laravel Package

Product Decisions This Supports

• De-risks error-reporting roadmap work — an enabler, not a user-facing feature. Any ticket touching the Flare integration (custom exception context, breadcrumbs, middleware that mutates payloads, queue/job error reporting, trace spans) can be verified locally by reading the actual outgoing payload. That turns the feedback loop on a recurring class of work from "deploy to staging and wait for a real error" into "trigger one request and inspect the output."
• Build vs. buy: buy — at zero cost. A fake sender is not hard to write, but this package already handles the tedious parts a team would otherwise hand-roll: pass-through toggles for errors/traces/Zipkin, three pluggable output channels (Ray, Laravel log, file), trace/span ID and timestamp normalization so payload diffs are readable, and a swappable underlying cURL sender. MIT-licensed, one composer require, no service or account dependency, no data leaving the machine. Build in-house only if you need something the option list does not expose.
• Privacy and data-handling review input. print_full_payload combined with the passthrough_* flags makes it cheap to answer "exactly which fields — user IDs, request bodies, headers, session data — leave our application for a third party?" That is reusable evidence for a security or privacy sign-off on error tracking, and far more convincing than reading SDK source.
• Testing strategy and CI boundaries. The author positions this as "mostly used for internal testing purposes." Treat it as a local developer utility, not a test harness. It supports the decision "we do not need a mock-Flare fixture layer for this suite," but it should not become a pinned CI dependency without a named owner, because its contract tracks Flare majors (2.0.0 exists solely to follow the v3 Flare packages).
• Upgrade validation gate. Before and after a Flare major upgrade, run the same failing request through this sender and diff the payloads. Concrete, low-effort migration check.
• Representative use cases:
  • Confirm a new custom exception carries the context fields you intended, in the shape Flare expects.
  • Reproduce an environment-specific or intermittent failure locally without burning staging error quota or polluting the dashboard.
  • Onboard engineers onto the error-tracking setup by showing a real payload instead of a dashboard abstraction.
  • Verify middleware or handlers that rewrite error payloads before dispatch.
  • Audit what a route currently reports before adding filtering or sampling rules elsewhere.

When to Consider This Package

Adopt if:

• You use Spatie Flare as your error tracker, on an SDK version whose config supports overriding the sender class. The README assumes a published config/flare.php with a sender key — confirm that against your installed Flare version before promising anything to a team.
• Engineers regularly need to answer "what exactly did we send to Flare?" — payload shape, trace IDs, resource data, endpoint.
• You want a local toggle rather than a new tool in the stack: Ray if the team already uses it, otherwise the Laravel log or a plain file, with no new infrastructure.
• You are mid-migration between Flare majors and want a before/after payload comparison.

Look elsewhere if:

• You do not use Flare. This is single-purpose tooling for one vendor's payload format. Laravel Telescope, Ray, Xdebug, or a plain Log::debug covers comparable ground, and Telescope covers far more.
• You need real debugging or profiling — step-through debugging, query analysis, memory profiling, distributed tracing. Xdebug, Telescope, or OpenTelemetry are the right tools; this package only tells you what Flare would have received.
• You want a production or staging safety net. This sender intercepts payloads; misconfigured in a shared environment it silently stops real errors from reaching Flare. Gate it behind an environment check and never enable it outside local. Note also that the README's sample config disables TLS certificate verification (CURLOPT_SSL_VERIFYHOST => 0, CURLOPT_SSL_VERIFYPEER => 0) — acceptable for a local throwaway, not something to copy into shared config.
• You need maintained, community-validated dependencies. Zero stars and zero dependents means no external validation and a single-vendor bus factor. Pin the version, assume the sender config contract can shift with Flare majors, and do not build internal tooling on its internal classes.
• Error volume or cost control is the actual problem. Sampling, filtering, and quota management live in the Flare SDK and dashboard, not here.

How to Pitch It (Stakeholders)

For executives (one paragraph). This is a free, MIT-licensed developer utility that lets our engineers see exactly what our application sends to Flare before it is sent. It is not a customer-facing feature and costs nothing to adopt beyond a small amount of setup time. Its value is speed and confidence: work on error reporting currently gets validated by deploying to staging and waiting for a real failure, and this shortens that to a single local request. It also gives us a credible way to verify what user data actually leaves our systems when an error is reported — useful input to any privacy or security review. The main caveat is maturity: it is a single-vendor, near-zero-adoption package explicitly described as an internal testing tool, so it should be treated as a local convenience and pinned to a version, not as infrastructure we depend on.

For engineering (short version). If you have ever shipped a change to exception context, breadcrumbs, or trace handling and then guessed whether Flare received what you intended, this closes that gap. Set it as the sender in config/flare.php, pick an output channel (Ray if you already run it, otherwise the Laravel log or a file), and the payload is printed instead of sent. The toggles for passthrough of errors, traces, and Zipkin, plus the ID and timestamp replacement, exist so the output is stable and readable enough to diff. Two rules: enable it only in local environments, since it suppresses real reporting, and do not copy the sample config's disabled TLS verification into anything shared. Expect minor churn on Flare major upgrades — 2.0.0 shipped purely to track Flare v3 — so pin it and re-verify after any Flare bump.

Ask. Approve a timeboxed trial by one engineer on the current Flare integration, with a short write-up of whether the payload output was readable enough to be useful and whether the sender override works on our pinned Flare version. Success looks like one real payload bug caught locally that would otherwise have shipped, or a Flare upgrade verified with a payload diff. If neither happens within the timebox, we drop it and keep using Telescope.