Async Request Bundle Laravel Package

Getting Started

Install the package via Composer and, if the package ships configuration, publish it with php artisan vendor:publish. Start with the README and the notification class/trait that adds request support; that is where the serialization behavior lives.

The first use case is passing the current request into a notification so it can be handled later, including from a queued notification. In a controller or form request, read the body before dispatching:

$request->getContent(); // required before the request is serialized

Notification::send($user, new RequestAwareNotification($request));

If you are upgrading to 1.1, the key change is that the request body must be read explicitly before dispatch. Add $request->getContent() anywhere before the notification is sent.

Implementation Patterns

• Controller dispatch: Capture the request, call getContent() if you need the body, then pass the request into the notification. This works for both synchronous and queued notifications.
• Form requests: FormRequest extends Illuminate\Http\Request, so the same pattern applies. Call getContent() before dispatch if the notification needs the raw body.
• Queued notifications: When the notification implements ShouldQueue, the request is serialized at dispatch time. Read the body before dispatch so the deserialized request contains it.
• Selective payloads: If you only need a subset of request data, consider passing a DTO or array instead of the full request. This avoids serializing sensitive fields and sidesteps the php://input constraint.
• Middleware/workflow tip: If a request will be used in a notification later in the request lifecycle, read the body early (for example in middleware or at the start of the controller action) rather than relying on the request being fully populated at dispatch time.
• Custom serialization: If the package exposes a serializer or request wrapper extension point, use it to control which request attributes are persisted. This is useful for excluding headers, files, or sensitive input.

Gotchas and Tips

• php://input is single-read: PHP’s php://input stream cannot be rewound. Laravel’s Request may not have read the body yet when the notification is dispatched. The 1.1 release note is explicit: call Request::getContent() before dispatching a notification with the request object. Otherwise the body is not read from php://input and will not be available after deserializing the request.
• Debugging missing body: If a queued notification receives a request with an empty body, check that getContent() was called before dispatch. Inspect the serialized payload if the package provides a way to do so.
• Sensitive data: Serializing a full request can persist headers, tokens, and user input. Sanitize or use a DTO when the notification does not need everything.
• Synchronous vs queued: The body-read requirement is most visible with queued notifications, but it also matters anywhere the request is serialized and later deserialized. Treat getContent() as a precondition whenever the request object is passed into the notification layer.
• Extension points: Look for package hooks around request serialization/deserialization. These are the right place to normalize or filter request data rather than modifying the notification class itself.