Weave Code
Kendo Error Tracker Laravel Package
script-development/kendo-error-tracker
Laravel package for tracking application errors, capturing exceptions, and surfacing reports for faster debugging. Helps centralize error visibility and streamline troubleshooting in Kendo-based projects.
Laravel client library that reports scrubbed exceptions into kendo's error-tracking endpoint.
Frequently asked questions about Kendo Error Tracker
- How do I install script-development/kendo-error-tracker in a Laravel app?
- Install it with Composer using composer require script-development/kendo-error-tracker, then follow the README to register the service provider and publish any configuration the package ships. The package integrates through Laravel's service container, so setup is mostly configuration plus a single provider registration. Because it is a 0.x release, pin an exact version in composer.json before deploying.
- Which Laravel and PHP versions does kendo-error-tracker support?
- The authoritative compatibility matrix is the require section of the package's composer.json, which lists the supported PHP and illuminate/* constraints. Check that against your application's Laravel and PHP versions, and review the README for any explicitly tested combinations. Because the package is pre-1.0, treat releases as potentially behavior-changing and pin exact versions.
- How does kendo-error-tracker capture exceptions in Laravel?
- The package reports application errors and exceptions into Kendo's error tracking endpoint, centralizing visibility instead of relying on local logs alone. It integrates through Laravel's service container, so registration and configuration follow standard package conventions. Reports are scrubbed and authenticated before transmission, and reporting failures are swallowed so they cannot break your application's request cycle.
- How do I prevent sensitive data from being sent to kendo?
- The package performs scrubbing before reports leave your application, so configure the scrub rules to cover request parameters, headers, and any custom context you attach. Treat scrubbing as defense in depth: avoid putting secrets into exception messages or custom context in the first place. Review the README's scrubbing section and verify with a real exception in staging before relying on it in production.
- How do I authenticate reports to the kendo error tracking endpoint?
- Authentication credentials for the kendo endpoint are supplied through the package configuration, typically via environment variables so they are not committed to source control. The client authenticates outbound reports as part of the send path, so you only need to provide valid credentials for your Kendo project. Keep separate credentials per environment so staging errors never land in production dashboards.
- What happens if the kendo endpoint is down or returns an error?
- The client is fail-open by design: failures while reporting are swallowed so an outage at the tracking endpoint cannot break your application's requests. That favors availability over guaranteed delivery, which means individual reports can be lost during an incident. Monitor your application's own logs and error rates rather than assuming the kendo dashboard is complete during endpoint outages.
- How do I scope user hashes per tenant in a multi-tenant Laravel app?
- Register a resolver with app(ErrorTracker::class)->scopeUserHashUsing(...) inside a service provider or tenancy bootstrapper that runs after tenancy is initialized. The tenant key is folded into the hash's key material but never included in the outbound payload, so user correlation works within a tenant while cross-tenant collisions are eliminated. Make sure the closure reads the current tenant dynamically with a container lookup or request-scoped accessor rather than capturing a tenant value at registration time.
- Why did my user_hash values change after upgrading from 0.2.0 to 0.2.1?
- Version 0.2.1 changes the hash key material for multi-tenant apps by folding in the tenant key, which fixes cross-tenant collisions tracked as KD-1978. As a result, hashes for the same user will not match those emitted under 0.2.0, so expect a discontinuity in per-user report history at the cutover. Single-tenant apps are unaffected: with no resolver, or a resolver returning null, the package reproduces v0.2.0 hashes exactly.
- Does kendo-error-tracker work with queued jobs, Octane, and the scheduler?
- Those long-lived and non-HTTP contexts are where tenant scoping gets subtle: a queue worker, console command, or Octane worker may have no tenant bound when the report is created. Use a resolver that reads tenant context dynamically so it behaves correctly per request and per job instead of leaking a captured tenant across executions. If no tenant is available the resolver should return null, which falls back to the v0.2.0 hash behavior, so confirm the exact enqueue-versus-send timing in your setup.
- How should I test kendo-error-tracker before deploying?
- Point the package at a staging or test endpoint and throw a deliberate exception to confirm the report arrives, the payload is scrubbed as expected, and authentication succeeds. Also test the failure path by making the endpoint unreachable to verify that reporting errors are swallowed and your application continues to respond normally. If you use multi-tenancy, test from both an HTTP request and a queued job to confirm the resolver reads the correct tenant in each context.
Weaver
How can I help you explore Laravel packages today?