Kendo Error Tracker Laravel Package

Technical Evaluation

Architecture fit. kendo integrates through Laravel's service container (app(ErrorTracker::class)->scopeUserHashUsing(...)), so tenant scoping is a single registration rather than a config file or schema change. The design is sound for the stated deployment model (database-per-tenant, ids restarting per tenant): the tenant key is folded into the hash's key material, never into the outbound payload, so user correlation survives within a tenant while cross-tenant collisions are eliminated. Backwards compatibility is explicit — no resolver, or a null return, reproduces v0.2.0 hashes exactly — which keeps single-tenant deployments byte-identical and makes this a safe patch for the majority of installs.

Integration feasibility. Low. One closure in a service provider or tenancy bootstrapper, plus a documented README path ("Multi-tenant apps"). Failure handling is fail-open for availability: a resolver that throws or returns a non-integer/non-empty-string yields no user_hash and the report is still transmitted, so error visibility is never lost to a scoping bug.

Technical risk. Concentrated, not broad:

• Historical contamination. The fix is forward-only. Reports already emitted under v0.2.0 by multi-tenant apps may have been cross-linked in the vendor's UI ("counted them as one affected user and could link their reports"). This is a confidentiality issue in the product surface, not just a counting bug — it warrants a separate question about disclosure obligations, alert/notification routing, and whether affected history can be segmented or purged.
• 0.x versioning. Patch-level release with behavior that changes for multi-tenant apps; SemVer guarantees are weak pre-1.0. Pin exact versions.
• Silent degradation. "No hash" is an invisible state. There is no stated logging or metric when the resolver throws or returns an invalid type.

Key questions.

1. When is the closure evaluated — at report creation or at transmission? If reports are queued, is the tenant captured at enqueue time or re-resolved in the worker (where tenant context is typically absent)?
2. What is the behavior in console, scheduler, and queued-job contexts where no tenant is bound? Presumably null → v0.2.0 hash → collisions persist for those paths.
3. Does registering the resolver twice, or after the tracker has already resolved a hash, raise or silently overwrite? Is registration per-process safe under Octane?
4. What exactly constitutes the hash key, and does it remain stable across APP_KEY rotation or tenant-key changes? Can the hash be recomputed by the vendor (i.e., is the tenant key ever recoverable server-side)?
5. Is the exception from a throwing resolver swallowed quietly, logged, or itself tracked (recursion risk)?
6. Is there a security advisory or CVE associated with KD-1978, and what is the vendor's position on already-mis-linked historical data?
7. Supported Laravel/PHP version matrix, and whether Octane/Horizon are explicitly tested.

Integration Approach

Stack fit. Targets Laravel apps using database-per-tenant isolation (stancl/tenancy, tenancy-for-laravel, or in-house). The prerequisite is that tenant context is resolvable at the moment the tracker hashes a user — not merely during HTTP middleware.

Migration path. Upgrade to 0.2.1, then register the resolver in a bootstrapper that runs after tenancy initialization. Confirm the callback reads current tenant context dynamically (a container lookup or request-scoped accessor) rather than capturing a tenant value at registration time; a captured value would leak across requests under Octane and across jobs in a long-lived worker. No migrations, config publishes, or data backfills are implied by the release note.

Compatibility. Single-tenant apps: no action required, hashes unchanged. Multi-tenant apps on v0.2.0: action required, and note that existing hashes will not match new ones for the same user — expect a discontinuity in per-user report history at the cutover unless the vendor provides a re-keying path. Verify the package's Laravel/PHP constraints before adopting, as none are stated in the release note.

Sequencing.

1. Pin 0.2.1 in composer.
2. Add resolver registration; review ordering against tenancy bootstrappers.
3. Stage with two tenants that both have user id 42; assert distinct user_hash values.
4. Capture outbound payloads and confirm the tenant key is absent on the wire and in local logs.
5. Exercise the three degradation paths: no resolver, null return, throwing resolver, invalid return (including empty string — a plausible tenant key for a default tenant).
6. Repeat steps 3–5 from a queue worker, an artisan command, and (if applicable) an Octane worker.
7. Roll to production; re-verify worker processes were restarted with the new code and resolver.

Operational Impact

Maintenance. Small surface area, but the closure becomes coupled to the tenancy package's lifecycle and context API — a tenancy upgrade can silently break it. Add a regression test asserting two tenants with identical user ids produce different hashes; that test is the cheapest guard against a future silent regression. Track releases closely given 0.x cadence.

Support. The vendor's handling is a positive signal: a targeted fix, an explicit no-change guarantee for the common case, defined behavior for every resolver failure mode, and documentation shipped alongside. Counterweights: 0.x maturity, no stated support window or LTS, and no published security process visible from this note alone.

Scaling. Per-report closure invocation is negligible. The real scaling concern is state: any caching of the tenant key inside the resolver (memoization, static, singleton property) becomes a cross-tenant leak vector under Octane or long-lived queue workers. Mandate a stateless resolver and verify with a load test that interleaves tenants.

Failure modes.

• Resolver throws or returns an invalid type → no user_hash; reports still arrive but affected-user counts, deduplication, and any user-linked alerting degrade silently.
• Resolver returns null (including "tenant not bound" in jobs/CLI) → v0.2.0 behavior → cross-tenant collisions resume on exactly the asynchronous paths most likely to carry background errors.
• Resolver returns a tenant key that is not unique or not stable (e.g., a display name, or a key that changes on tenant rename) → hash churn, fragmenting the same user across multiple hashes.
• Registration placed before tenancy bootstrapping → resolver sees no tenant on the first report of a request.
• Historical v0.2.0 data stays cross-linked; no automatic remediation.

Ramp-up. One engineer, well under a day for the happy path; the majority of the effort is validating tenant context in asynchronous execution paths and confirming payload hygiene. Budget additional time for the historical-data and disclosure conversation if the product surface genuinely exposed cross-tenant report linkage — that is a product and legal question, not an engineering one, and it should be answered before the upgrade is treated as closed.