- Can I install darkwood/ia-exception-bundle in a Laravel application?
- No. The package is a Symfony bundle that requires PHP 8.5+ and Symfony 8.x, and it attaches to Symfony's kernel.exception event with Twig error templates and service-ID based agent resolution. Laravel has no bundles, no kernel.exception listener hook, and no Twig-by-default rendering, so direct installation is not viable on a Laravel codebase. Treat the repository as a reference implementation and port the pattern instead.
- Does this bundle integrate with Laravel's withExceptions() handler?
- There is no integration layer. The bundle's entry point is a Symfony event listener registered against kernel.exception, while Laravel's equivalent surface is the withExceptions() callback in bootstrap/app.php. You would need to reimplement the listener logic as a renderable exception handler or a reportable hook. Nothing in the package is framework-agnostic, so no adapter exists.
- How do I add AI-generated explanations to 500 error pages in Laravel?
- Port the bundle's pattern rather than its code: intercept 5xx exceptions in withExceptions(), sanitize the class, message, file, and line, compute a fingerprint, and check the cache before calling an LLM. If you want the non-blocking behaviour, dispatch a queued job and render a Blade partial with a placeholder that is hydrated later. The bundle's own logic surface is small — a listener, a prompt builder, a cache key, and one async controller — so a Laravel port is roughly one to two weeks of engineering.
- What PHP and Symfony versions does darkwood/ia-exception-bundle require?
- It requires PHP 8.5+, Symfony 8.x, and a configured symfony/ai-bundle with a platform and agent defined. Those are bleeding-edge constraints that will conflict with most Laravel estates still running PHP 8.2 through 8.4. The symfony/ai-bundle dependency is also pre-1.0 and has moved through several minor versions in a matter of months, so version churn is a real schedule risk.
- How is darkwood_ia_exception configured?
- Configuration lives in a darkwood_ia_exception YAML tree with keys for enabled, only_status_codes, agent, timeout_ms, cache_ttl, cache, include_trace, async, async_route_prefix, and async_context_ttl. It is disabled by default and only augments the status codes you list, with include_trace intended for development only. If you mirror this in Laravel, a config/ai_exceptions.php file with the same semantics keeps the mental model intact.
- Is it safe to send exception messages and stack traces to an LLM?
- Treat it as a vendor data-processing question, not just a config toggle. Exception messages routinely contain SQL fragments, table and column names, absolute file paths, and occasionally tokens, all of which leave your boundary when sent to a third-party model. Keep include_trace false in production, confirm a DPA with the model vendor, and note that the bundle's async endpoint ships unauthenticated by default, so it needs auth, rate limiting, and a documented retention policy for async_context_ttl.
- How does async mode work and can I replicate it in Laravel?
- With async set to true the error page returns immediately with an AI analysis placeholder, and an inline script fetches GET /__ai_exception/{error_id} with a 30-second timeout and a graceful fallback message. That avoids blocking kernel.exception, which otherwise directly extends user-facing 500 latency. In Laravel the natural equivalent is a queued job writing to cache plus a polling or streaming route, which also gives you retries and rate limiting for free.
- How does the PSR-6 exception cache work and how do I mirror it with Laravel's Cache?
- The bundle stores analyses in a PSR-6 cache service, cache.app by default, keyed by a fingerprint built from the exception class, message, and top frames, with a default TTL of 600 seconds and zero disabling it. Identical exceptions then reuse the stored explanation instead of triggering another paid LLM call. In Laravel, use the Cache facade with the same fingerprint strategy and always fall back to a null or short TTL store when the cache backend is unavailable.
- How would I test AI exception analysis in a Laravel app before production?
- Bind the analyzer behind an interface and swap in a fake in your test suite so no real LLM call is made. Assert that a cache hit skips the client entirely, that a thrown exception from the client leaves the original 500 response untouched, and that trace data is excluded when the production config is active. For vendor SDK calls, Http::fake() plus an assertion on the outgoing payload catches accidental leakage of sensitive fields.
- Is darkwood/ia-exception-bundle production-ready and what are the Laravel alternatives?
- It is a single-maintainer package with a handful of stars, no dependents, and releases that mirror Symfony patch versions, so you would be an early adopter with no third-party validation. There is no Laravel equivalent, so the realistic options are porting the pattern into your own package, running a Symfony 8 sidecar service that Laravel forwards exception payloads to, or extending an existing error tracker such as Sentry or Flare with an AI summary layer. Whichever route you choose, cap per-incident AI spend, since error volume spikes exactly when you can least afford latency.