Resource Lock Laravel Package

Technical Evaluation

Package: kenepa/resource-lock — a Filament plugin that places advisory locks on Eloquent records so two editors cannot open the same record in an edit form concurrently. It is a single-purpose, admin-panel-scoped utility, not platform infrastructure.

Architecture fit. The package sits at the Filament resource layer, hooking edit-page lifecycle (acquire on open, release on save/close/expiry) and surfacing a "locked by X" state in the UI. That is a narrow, well-bounded responsibility — attractive from a TPM standpoint because it adds concurrency safety to Filament admin panels without touching domain models, queue workers, or API surfaces. It complements rather than competes with database-level optimistic locking; teams should understand it solves editor collision UX, not write-write consistency. If our admin surfaces are Filament-based and used by more than a handful of operators on shared records, fit is high. If Filament is peripheral to the product, this is low-value.

Breaking-change signal. The 3.0.1 → 4.0.0 jump is a major version, and the changelog attributes it to "Filament 4.x" support (PR #65) plus general improvements (PR #68). The realistic reading: 4.0.0 tracks Filament v4's API surface, and the major bump exists because the plugin can no longer support Filament 3 and 4 from one codebase. This implies (a) a hard coupling between our Filament major version and this package's major version, and (b) that our upgrade to this package is gated on — and should be sequenced with — a Filament 4 migration, not treated as an independent dependency bump. The changelog is thin: no explicit "Breaking Changes" or upgrade-guide section, no migration notes for published config/migrations, no mention of lock-table schema changes.

Integration feasibility. Composer-installable Laravel package with a Filament panel plugin registration and, typically, a published migration for the lock table plus a publishable config. Effort is measured in hours for a greenfield install. The nontrivial work is not installation but behavioral verification: confirming lock acquisition/release semantics on our page types (custom pages, relation managers, modal-based editing, bulk actions), and confirming that locks release cleanly on browser close, session expiry, and failed validation.

Technical risk. Medium, concentrated in three places. (1) Ecosystem coupling: a Filament 4 upgrade is itself a large migration; this package inherits that risk and adds a dependency that must be re-validated on every Filament major. Maintainer bandwidth is the underlying exposure — two contributors on the 4.0.0 release, one a first-time contributor, and a single primary maintainer behind the package. (2) Stale locks: any advisory lock scheme leaks locks when clients disconnect ungracefully; if expiry/refresh is not robust, users get locked out of records and support tickets follow. (3) Multi-tenancy and authorization: whether lock keys are scoped correctly across tenants, and whether users who can view but not edit a record are handled sanely.

Key questions.

• Does our application run Filament 3 or 4 today, and is a Filament 4 migration already on the roadmap? If not, 4.0.0 may be unusable and we should pin 3.0.x.
• What are the exact constraints (PHP version, Laravel version, Filament ^4.0) and do they intersect our supported matrix?
• Does 4.0.0 change the lock table schema or config keys? Is there a documented upgrade path from 3.0.1, or is a fresh migration expected?
• How are locks expired and refreshed — TTL, heartbeat, session-bound, or explicit release? What is the recovery path when a lock is orphaned?
• Are locks tenant-scoped and policy-aware by default, or does that require customization?
• What is the maintainer's stated support policy across Filament majors — does 3.x continue to receive fixes?

Integration Approach

Stack fit. Assumes Laravel + Filament with a relational database and a cache/session store available for lock bookkeeping. No queue, no external service, no vendor account — operationally cheap and easy to justify. Fits a standard internal-tooling or back-office admin stack cleanly. Does not fit if admin editing happens through bespoke Blade/Livewire pages outside Filament resources, or through an external CMS/API where our lock would be advisory at best.

Compatibility. The decisive variable is our Filament major version, and it is binary: Filament 3 → stay on 3.0.x; Filament 4 → 4.0.0 is the only supported line. Do not attempt to run both across a multi-panel application unless all panels share one Filament major. Verify PHP/Laravel constraints from composer.json against our matrix before committing; the changelog does not state them.

Migration path. Two distinct scenarios, and they should not be conflated.

• Already on Filament 4: treat 4.0.0 as a plugin upgrade. Review the diff for config/migration changes, re-publish the config into version control, run the migration if the lock table changed, and re-verify lock behavior in a staging panel. Low effort, but do not skip the behavioral pass — the "Improvements" commit is unreviewed from our side.
• Still on Filament 4's predecessor: 4.0.0 is not an option in isolation. Sequence it inside the Filament 4 migration as a follow-on task, not a prerequisite. Do not upgrade the plugin first and hope Filament catches up.

Sequencing. (1) Confirm Filament major and PHP/Laravel matrix. (2) Read the 3.0.1→4.0.0 diff, with specific attention to config keys, migration files, and any renamed interfaces or page hooks. (3) Spike in a branch: install, publish assets/config, verify acquire/release on every page type we actually use. (4) Test the failure modes deliberately — kill the browser mid-edit, let a session expire, submit invalid data repeatedly. (5) Roll out behind a feature flag to one low-traffic panel, then widen.

Guardrails. Pin the version explicitly in composer.json rather than floating on ^4.0, given the release cadence and single-maintainer risk. Add a Renovate/Dependabot watch so the next Filament major surfaces as a planned work item rather than an emergency.

Operational Impact

Maintenance. Low ongoing code maintenance, moderate upgrade maintenance. The package is small and the surface is narrow, but its release cycle is chained to Filament's — expect a required major bump of this package on every Filament major. Budget that as a recurring, predictable line item rather than a surprise. Also budget for reviewing thin changelogs: 4.0.0's notes list two PRs and no breaking-change detail, so we carry the diff-reading cost ourselves.

Support and bus factor. The real operational risk. A single primary maintainer with recent first-time contributions means: no formal SLA, no guaranteed security turnaround, and a plausible path to abandonment between Filament majors. Mitigations are cheap and worth doing now — read the diff before adopting, keep a fork-ready posture (it is a small package, so a vendored patch is realistic), and avoid letting it become load-bearing for anything beyond editor-collision UX. Do not extend it into a general-purpose concurrency control mechanism for business logic.

Scaling. Negligible runtime cost at our scale: one row/entry per active edit session plus a check on page load. Grows with concurrent editors, not with data volume or request rate, so it does not create a scaling ceiling. Watch two things: (1) lock-table growth if rows are not cleaned up on expiry, and (2) write contention on the lock table if hundreds of editors are active simultaneously — likely irrelevant for back-office tooling, worth a glance if the panel is customer-facing.

Failure modes. Enumerate and test them:

• Orphaned lock (browser crash, network drop, session timeout) → user permanently blocked from editing. Highest-frequency real-world failure; must have a documented admin override or automatic TTL.
• Release failure on save → stale lock after a successful save; user sees a phantom conflict.
• Race on acquire → two editors both obtain the lock during a narrow window; check whether acquisition is atomic at the database level.
• Filament upgrade drift → plugin silently incompatible after a Filament minor, with locking quietly no-ops rather than erroring. Verify locks are actually being taken after any Filament upgrade, not just that the page renders.
• Multi-tenant leakage → lock keys not tenant-scoped, producing cross-tenant phantom conflicts.
• Abandonment → no fix available for a Filament 5 incompatibility; fallback is removing the plugin or vendoring it.

Ramp-up. Minimal for developers — install, register the plugin on the panel, publish config, done; a mid-level engineer is productive in under a day. The real ramp-up is operator education: users must understand that a lock means "someone else is editing, wait or ask them to finish," not "the record is broken." Without a short note in internal docs and a clear message in the UI, expect a first-week spike in "I can't edit this record" tickets that reads as a bug rather than the feature working. Pair the rollout with a stated override procedure for whoever holds admin rights.

Verdict. Adopt 4.0.0 only if we are on, or concurrently moving to, Filament 4. The package is a reasonable, low-cost improvement to admin-panel correctness with a contained blast radius. The decisions that matter are not technical — they are the Filament-version gate, the explicit version pin, and accepting a single-maintainer dependency with a documented fallback.