It was ShouldQueue, so on QUEUE_CONNECTION=database with no worker running
(or just queue lag), a booking stayed Confirmed in the UI until a worker
processed the job — refund actions in Filament looked like they hadn't
taken effect without a page reload. A refund is always initiated from a
request already waiting on it (the Filament action or the API endpoint),
so there's no reason to defer the status flip.
Nyan Lin Paing
825320a117