Sync bookings to .net bookings calendar

[kristiankunc]

No description provided.

[linear]

TECH-676

[github-actions]

🔍 OpenCodeReview found 2 issue(s) in this PR.

• ✅ Successfully posted inline: 2 comment(s)

[github-actions]

[performance · medium]
This HTTP client makes outbound calls to VATSIM.net from a queued worker (SyncToVatsimNet) without any timeout. Guzzle's default timeout/connect_timeout is 0 (wait indefinitely), so a stalled or unresponsive VATSIM.net endpoint can hold a Horizon worker open for an unbounded amount of time. Add explicit ->timeout(...) / ->connectTimeout(...) (e.g. 15s) when building the pending request.

[github-actions]

[bug · high]
This observer dispatches the queue job from created/updated/deleted, but it does not implement ShouldHandleEventsAfterCommit. Booking creation and deletion are wrapped in DB transactions (e.g. MentoringSessionsService::acceptSession() -> createCoreBooking(), and BookingService::cancelCtsBooking() -> DB::connection('cts')->transaction(...)). Two consequences follow:

1. On a sync queue driver (tests/dev), the job runs before the transaction commits, so Booking::find($this->bookingId) in the job returns null and the sync is silently skipped (created bookings never reach VATSIM.net).
2. If the enclosing transaction later rolls back, the job has already been enqueued and will create/update a remote booking for a record that never persisted.

Other observers in this project (e.g. RosterObserver, TrainingPlaceObserver) already implement ShouldHandleEventsAfterCommit for exactly this reason. Add implements ShouldHandleEventsAfterCommit to defer dispatching until after commit.