Events For Laravel Laravel Package

Technical Evaluation

Architecture fit

• Standard Laravel package shape: service provider, publishable config, publishable migrations under tag events-migrations, publishable routes/events.php, artisan commands (events:doctor, events:repair), a first-party fake (Events::fake()) with assertion helpers, policy-driven authorization, and JSON-LD serialization.
• Domain surface is broad but cohesive: events, tiers, RSVPs, holds, waitlist/promotion, checkouts and payment references, check-ins, reminders, invitations, co-hosts, labels/categories. Supports MySQL, MariaDB, PostgreSQL, SQLite.
• Host-model integration is convention-based (events.resources.*, events.organizers / events.attendees aliases) and now round-trips aliases in responses — a deliberate API-contract decision, not just an internal refactor.
• 1.1.0 is a correctness/compliance release: it closes authz gaps, fixes MySQL TIMESTAMP range and DST write failures, and tightens schedule math. Architecturally the package stays the same; the schema substrate changes on MySQL/MariaDB.

Integration feasibility

• Upgrade is a two-step: vendor:publish --tag=events-migrations (adds only 0008) then php artisan migrate. Feasible in a normal sprint, but the migration rebuilds seven tables on MySQL/MariaDB, so it is an operational change, not a code-only bump.
• Migration correctness depends on the session time zone of the connection that runs it matching the one that wrote the values. This is the single largest integration hazard and must be run as a controlled, scripted step — never ad hoc.
• Hosts that published routes/events.php must hand-edit middleware (UseConfiguredGuard on the outer group). Hosts that did not publish are unaffected.
• events:doctor gives a pre-flight/post-flight signal (warns while the events table still stores TIMESTAMP), which is useful for gating a rollout.

Technical risk

• Schema rebuild risk (High): altering TIMESTAMP → DATETIME on seven tables is generally a copying ALTER in MySQL/MariaDB, holding locks proportional to table size. Needs a window or an online-schema-change tool.
• Data-conversion risk (High if mis-run): instants are reinterpreted through the connection's time zone. A migration run with a different session zone than the app used will silently shift every timestamp.
• Authorization fixes (High value, moderate regression risk): PATCH /events/{event}/attendees/{rsvp} previously leaked the manager view to any signed-in user; read routes now recognise configured guards. Both are fixes worth expediting, but they change 403/422 behaviour that existing clients and tests may rely on.
• Contract changes (Medium): type now renders the configured alias (user) rather than the class basename (User); clients comparing on basename break. A manager's confirm() without a reference now means "paid another way" and drops the online checkout — downstream reconciliation/refund logic must be re-verified.
• Business-rule changes (Medium): guest additions can now throw EventFullException / TierSoldOutException when a waitlisted party would fit; rescheduling an announced event to a date already past returns 422 invalid_schedule; reschedule() clears draft doors time.
• Test-double semantics (Low–Medium): Events::fake() now records builder chains and attendee-initiated payment requests; assertNo…() pairs previously passed for no-op calls and now do not. Expect a wave of test failures that are corrections, not regressions.
• Security posture improvement: the PATCH leak and the guard-recognition bug mean pre-1.1.0 installs have a live data-exposure path; this raises upgrade priority beyond normal feature cadence.

Key questions

• Table row counts and largest-table size for events, RSVPs, and check-ins — and therefore expected lock duration?
• MySQL/MariaDB version, and is pt-online-schema-change / gh-ost available and permitted?
• Are routes/events.php and config/events.php published locally (i.e. does the manual middleware step apply)?
• Do any clients, exports, or downstream services compare type against a class basename?
• Does any code path call confirm() without a payment reference and currently expect the checkout to survive?
• Is Date::use(CarbonImmutable::class) in play (previously fatal on save)?
• Which guards are listed in events.routes.auth_middleware, and do read endpoints see the same caller identity as write endpoints after upgrade?
• Supported PHP/Laravel version matrix for 1.1.0 — not stated in the notes, must be confirmed before scheduling.

Integration Approach

Stack fit

• Assumes a conventional Laravel app on MySQL/MariaDB with queue workers for promotion, a payment provider for checkout, and token/guard-based auth (auth:sanctum called out). No non-standard infrastructure is introduced.
• PostgreSQL and SQLite deployments are effectively no-ops for 0008 — both column types are equivalent there — so only MySQL/MariaDB installs carry migration cost.
• Test suite alignment required: Events::fake() assertion semantics changed in both directions, so CI will be the primary detector of behaviour assumptions.

Migration path

1. Pin and upgrade the package to ^1.1; deploy application code first — 1.1 runs against the old TIMESTAMP schema (events:doctor warns), so deploy and migrate can be decoupled.
2. php artisan vendor:publish --tag=events-migrations; diff the published directory to confirm only 0008 is added and nothing previously published is rewritten.
3. If routes/events.php was published, add UseConfiguredGuard to its outer group and commit that edit alongside the dependency bump.
4. Run php artisan migrate with the application's exact DB connection env (host, database, session time zone) during a low-traffic window; capture row counts and migration duration for the runbook.
5. Run events:doctor and confirm the TIMESTAMP warning is gone; spot-check starts_at, sale windows, holds, check-ins, and created_at against a pre-migration snapshot.
6. Reconcile data: any open holds with online checkouts, pending payment references, and events scheduled beyond 2038-01-19.

Compatibility

• 1.0 → 1.1 is a single hop with no deprecations announced; the breaking surface is behavioural (alias type, confirm() semantics, guest/waitlist precedence, stricter 422s), plus the mandatory middleware edit for hosts with published routes.
• Irreversible in practice: no down migration is described. Rollback is snapshot/restore, so a restore point must be taken immediately before migrate.
• Config keys (events.resources.*, events.schedule.max_duration, waitlist.stop_promoting_before, events.routes.auth_middleware) are read, not renamed — but semantics shift (duration now measured in the event's own time zone or elapsed time, whichever is more permissive).

Sequencing

• Rehearse on a production-shaped snapshot, ideally with a DST-observing MySQL session zone (Europe/Bratislava is the exact scenario called out) to prove both the conversion and the spring-forward write path.
• Ship code, then schema, then verify, then enable the behaviour changes for real traffic — and only after client-side type comparison and confirm() call sites have been audited.
• Front-load the upgrade if the PATCH attendee leak or the guard-recognition bug is reachable in the current deployment.

Operational Impact

Maintenance

• Published migrations and published routes become local artifacts that must be re-diffed each release; the middleware step is precisely the kind of instruction that rots. Prefer leaving routes unpublished, or track the delta in the upgrade checklist.
• Expect ongoing upkeep of events.resources.* mappings as host models and aliases evolve; the alias is now the public contract.
• Test suites need a one-time reconciliation pass on fake assertions, then should be stable.

Support

• New user-visible failure signals to document for support: 403 (non-manager PATCH), 422 naming missing tier/guests, 422 invalid_tier for over-precise currency amounts, 422 invalid_schedule for reschedules into the past, EventFullException / TierSoldOutException when guests are added while a waitlist would fit, and RsvpPaymentRequestDiscarded when a hold is refreshed mid-checkout.
• confirm() without a reference is now a semantic "cash at the door" signal with wasPaid: false on exit; support scripts for refunds and attendance reporting must reflect that.
• The corrected check-in lifecycle (leaving clears the check-in record; re-added attendees may decline again) will change what managers see versus what they remember — brief frontline staff.

Scaling

• DATETIME and TIMESTAMP index characteristics are comparable; query performance should not regress and 2038 and DST-gap write failures disappear.
• The migration itself is the scaling concern: lock time scales with the seven tables' row counts. For large installs, use an online schema-change tool or a replica-first approach rather than a literal migrate on the primary.
• Promotion and waitlist work already runs through the queue; the new waitlist-priority rule on guest additions adds a synchronous check on a hot path — worth watching under load.

Failure modes

• Migration interrupted mid-rebuild → partially altered tables; requires restore, so make the migration idempotent-by-restore, not retry-in-place.
• Migration run under the wrong session time zone → silently shifted instants across all seven tables; detected only by spot-check, hence the mandatory verification step.
• Missing UseConfiguredGuard → authenticated callers read as guests on read routes (private events, own RSVP, filter[mine], online link), i.e. a quiet functional and privacy regression rather than an error.
• Clients parsing type as class basename → silent misrouting in client code, not a server error.
• Checkout races: stale checkouts are now discarded and reported rather than attached to a refreshed hold; any reconciliation job matching by amount must handle the discard path.
• Legacy confirm() behaviour in downstream code → refunds issued against a checkout the package already dropped, or double-charges at the door.

Ramp-up

• Engineering: half a day on the migration runbook, fake assertion changes, and the alias contract; one engineer owns the migration window and restore point.
• Product/support: brief on confirm() semantics, waitlist precedence for guests, past-date reschedule rejection, and the new 422 codes.
• Client/integration owners: audit type comparisons and any consumer of the attendee PATCH response before rollout.
• Treat the authz fixes as a security-driven upgrade: schedule it ahead of ordinary feature work and verify the PATCH and read-route behaviours explicitly in staging.