Kendo Error Tracker Laravel Package

Product Decisions This Supports

• Multi-tenant readiness: v0.2.1 removes a correctness and privacy blocker for per-tenant database architectures. If tenant ids restart (e.g., user 42 in two tenants), the package no longer merges them into one affected user or links their reports.
• Privacy-by-design positioning: The tenant key only salts the user hash locally and is never sent. This supports customer-facing claims that tenant identifiers and PII do not leave the application.
• Trust in error metrics: “Affected users” counts and report grouping become reliable for B2B/SaaS customer health, incident communications, and per-tenant error dashboards.
• Build vs. buy: A single resolver hook (scopeUserHashUsing) avoids building custom tenant-scoped hashing and user attribution plumbing.
• Roadmap enablement: Supports an enterprise or multi-tenant tier without requiring a fork or custom patch; existing single-tenant behavior is unchanged.
• Rollout sequencing: Teams can adopt this before a per-tenant database migration or enterprise launch rather than retrofitting attribution later.

When to Consider This Package

• You are on Laravel/PHP and need error tracking with user-impact attribution.
• You run multi-tenant applications—especially one database per tenant—where ids can collide across tenants.
• You need tenant-aware grouping without transmitting tenant identifiers.
• You want a lightweight, backwards-compatible resolver instead of custom instrumentation.
• Look elsewhere if you are single-tenant only and already satisfied with current hashing behavior; the release adds no value beyond v0.2.0 for that case.
• Look elsewhere if you already have mature tenant tagging and affected-user attribution in Sentry, Bugsnag, or an in-house system.
• Consider operational semantics: a resolver that throws or returns an invalid type sends no hash (report still sent), so teams must monitor resolver reliability if user attribution is business-critical.

How to Pitch It (Stakeholders)

For executives: v0.2.1 closes a multi-tenant correctness and privacy gap. Previously, the same user id in two tenants could be counted as one affected user and could link reports across tenants. The fix is small and backwards-compatible: single-tenant apps see no change, while multi-tenant apps register one resolver and get tenant-scoped user hashes without sending tenant identifiers. This de-risks per-tenant database rollouts and enterprise launches.

For engineering: Register app(ErrorTracker::class)->scopeUserHashUsing(fn (): int|string|null => …) once to return the current tenant key. The key salts the hash locally and is never transmitted. No resolver, or a null return, preserves v0.2.0 behavior exactly. Invalid returns or exceptions omit the hash but still send the report. The README’s “Multi-tenant apps” section documents registration. Recommend adopting before any per-tenant isolation work.