Weave Code
Laravel Same Request Laravel Package
inani/laravel-same-request
A lightweight Laravel package for detecting duplicate or repeated requests. It fingerprints incoming requests so you can identify identical submissions and handle them safely, helping prevent double form submissions, duplicate writes, and race conditions with minimal setup.
inani/laravel-same-request is a lightweight Laravel package that helps you detect whether code is executing within the same HTTP request — a common challenge when working with queued jobs, deferred callbacks, service containers, and long-running workers. It gives you a simple, reliable way to distinguish the current request lifecycle from subsequent ones, avoiding stale state and subtle bugs in event-driven or async workflows.
- Detects whether execution belongs to the original request
- Simple facade/helper API for quick checks in services and middleware
- Works cleanly with Laravel queues and long-running processes
- Prevents stale state leaking across request boundaries
- Zero-config setup with sensible defaults
Frequently asked questions about Laravel Same Request
- What does inani/laravel-same-request actually do?
- It is a small Laravel utility for coordinating logic within a single HTTP request, helping manage request-scoped state and avoid duplicate work. It is intended for once-per-request checks, flags, and guards tied to Laravel's request lifecycle. In practice it is best treated as lightweight duplicate-submission protection for form POSTs, webhook receivers, and non-critical API endpoints. It is not a system-wide idempotency layer unless keying, TTL, and response behavior are verified.
- How do I install and register inani/laravel-same-request in a Laravel application?
- Install it with Composer and rely on Laravel package auto-discovery for the service provider, then register the middleware on specific route groups rather than globally. Publish any configuration if the package provides it and pin the exact Composer version. Before wiring it into production routes, confirm its supported Laravel and PHP constraints and test middleware ordering against auth, throttling, CSRF, and body-consuming middleware.
- Which Laravel and PHP versions are supported by inani/laravel-same-request?
- The last release was in October 2023, so Laravel 11 and Laravel 12 compatibility is unproven. Test against Laravel 10 and 11 first and treat Laravel 12 as unsupported until you verify it in staging. Check the package's composer.json constraints for PHP and Laravel versions before adoption.
- What exactly counts as the same request in inani/laravel-same-request?
- That is a key question to answer from the source and tests before relying on it. The definition could include method, path, body hash, authenticated user, tenant, session, or selected headers. Ambiguous fingerprinting can cause false positives with file uploads or session-scoped data. Document the exact key scope your application needs and verify the package matches it.
- Does inani/laravel-same-request block concurrent duplicates or only sequential duplicates?
- The package overview does not clearly state whether it uses cache locks to block concurrent duplicates, simple flags for sequential duplicates, or both. Run parallel-request tests against your cache backend to see the actual behavior. If you need strict concurrency control, verify lock semantics or implement Laravel cache locks with a documented idempotency-key contract.
- Which cache store and TTL should I use with inani/laravel-same-request?
- It is best suited to applications already using Redis or a shared cache, especially across multiple nodes. File cache is a poor choice for multi-node duplicate detection. Confirm the required cache store, default TTL, and whether the package fails open or closed when the cache is unavailable. Tune TTL to your duplicate-submission window and document it.
- Is inani/laravel-same-request safe for payment, order, or webhook endpoints?
- Do not start with payment capture, refunds, or order creation because a duplicate-detected response without idempotent response replay can create client-side inconsistency. Use it first on low-risk, duplicate-prone routes such as contact forms and internal admin actions. Webhook intake is reasonable only when downstream handlers are already idempotent. Treat it as a tactical accelerator, not a critical-path idempotency layer.
- Does inani/laravel-same-request work with Laravel Octane and multi-tenant applications?
- Octane safety is unproven in the available context, so verify that request-scoped state does not leak across requests in long-lived workers. For multi-tenant applications, the request fingerprint must include tenant or user scope to avoid cache-key collisions. Test both scenarios in staging with representative traffic before production use.
- How should I evaluate inani/laravel-same-request before production?
- Run a one-to-two-day staging spike on representative endpoints and define the idempotency contract and key scope first. Add observability for duplicate hits and cache failures, then canary the middleware on a non-critical route. Load-test the cache path and document rollback by removing the middleware. Review test coverage, license, security posture, and the name/repo provenance mismatch before adoption.
- What alternatives should I consider if inani/laravel-same-request does not fit?
- A small in-house middleware using Laravel cache locks and a documented idempotency-key contract is often the safer fallback. You can also combine unique database constraints, rate limiting, and signed URLs depending on the endpoint. Treat the package as a reference implementation or tactical accelerator rather than a strategic dependency. Pin the exact version and keep an internal owner if you adopt it.
Weaver
How can I help you explore Laravel packages today?