Async Request Bundle Laravel Package

Product Decisions This Supports

• Feature/roadmap enablement: Anything where an inbound HTTP request must survive into a queued notification or job — form-submission acknowledgements, support-ticket intake, webhook forwarding, approval-request routing, audit/activity trails, error and exception reporting with full request context. The 1.1 note confirms this package is meant to carry the request object across the queue boundary, which makes those flows feasible without custom serialization code.
• Build vs. buy: The alternative is hand-rolling request snapshotting (extracting body, headers, method, and rehydrating them into a DTO) plus the queued-notification wiring. This release reduces that to a known one-line precondition, which strengthens the case for adopting rather than building — the remaining custom work is policy (what to capture, redaction, retention), not plumbing.
• Release scoping: Treat this as a patch-level, non-breaking guidance change, not a capability change. It documents an ordering requirement (Request::getContent() before dispatch) rather than adding a feature. No migration budget, no API surface change, no roadmap replan.
• Risk decision to make explicitly: Queued notifications serialize the request into the queue payload. That is a product/compliance decision about PII and secrets in queue storage and failed-job tables, not an engineering detail. Decide redaction and retention before rollout, not after the first incident.
• Adjacent product bet: If the roadmap includes customer-facing "we received your submission, here's exactly what we got" emails or admin replay of inbound requests, this package is the shortest path and 1.1 removes a silent-failure mode that would otherwise surface as empty-body bugs in production.

When to Consider This Package

Adopt when:

• You need the entire request — body plus headers, method, URL, content type — available inside a queued notification, not just validated input.
• You are already queued-notification-driven (Laravel's Notification/ShouldQueue with SerializesModels) and want to avoid writing and testing your own request DTO.
• You want a small, dependency-light package over a bespoke internal abstraction that nobody will maintain.
• Your flows are low-to-moderate volume: contact forms, feedback, intake, alerting — not high-throughput streaming.
• You can guarantee the documented ordering. The 1.1 note is a real footgun: if the body is never read from php://input before dispatch, it is unavailable after deserialization and the notification silently receives an empty body with no error. Bake this into code review or, better, into a wrapper that reads the content for you.

Look elsewhere or reconsider when:

• You only need validated fields. Use $request->validated() or a purpose-built DTO — smaller payloads, no serialization edge cases, no PII in the queue.
• Payloads are large or include file uploads. Queue payload size limits and serialization cost become the constraint; store an artifact and pass a reference instead.
• Requests carry credentials, tokens, or sensitive PII you cannot redact or encrypt at rest. The queue and failed_jobs tables are now a data store you must govern.
• You require strict forward compatibility across major Laravel versions and cannot absorb the maintenance of a thin third-party wrapper.
• High-volume or latency-critical paths where reading the body eagerly for every request is wasteful — read it only on the paths that actually notify.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a minor, non-breaking release of a small library we would use to pass incoming web requests into background notifications — the plumbing behind confirmation emails, support-ticket intake, and alerting. Version 1.1 does not add features; it documents one ordering rule that prevents a silent bug where notifications arrive with an empty request body. There is no migration cost and no change to our timeline. The real decision it surfaces is governance: once request data flows through the queue, we need a stated policy on redaction, encryption, and retention, because queue and failed-job storage becomes a place where customer data lives.

For engineering (short): Upgrade is safe — patch release, no API changes. The one action item: call Request::getContent() before dispatching a notification with the request object. Laravel/Symfony only reads php://input on demand, so if nothing reads it pre-dispatch, the deserialized request in the worker has an empty body — and it fails silently, which is the worst kind. Recommend we wrap dispatch in a helper that reads content first so this can't be forgotten, and add a test asserting body fidelity across the queue boundary. Also flag queue payload size and PII exposure in failed_jobs for review.