NotificationRegistry::notify() reads company settings from the session, but its callers are queued listeners

Start by locating NotificationRegistry::notify(), Setting::lookupCompany(), and the queued Fleetbase\FleetOps\Listeners\NotifyOrderEvent callers. Trace how the queued subject exposes company_uuid and how notifyUsingDefinitionName() reads settings. Done means queued notifications honor per-company notification_settings without a session, while retaining the stated session fallback when no company is available.

Summary

NotificationRegistry::notify() loads per-company settings with Setting::lookupCompany('notification_settings'), which bails out when there is no session:

public static function lookupFromCompany(string $key, $defaultValue = null)
{
    if (session()->missing('company')) {
        return $defaultValue;
    }

    return static::lookup('company.' . session('company') . '.' . $key, $defaultValue);
}

Its callers are queued: Fleetbase\FleetOps\Listeners\NotifyOrderEvent implements ShouldQueue. In the queue worker there is no session, $settings comes back empty, and the method notifies nobody.

Impact

On any deployment where the queue runs as its own process or container — including the documented docker-compose setup — everything configured in Settings → Notifications is silently ignored. The order notifications that do arrive are the hardcoded ones from HandleOrderDriverAssigned, HandleOrderDispatched, HandleOrderCanceled and HandleOrderDispatchFailed, which never consult the settings. The net effect is that the settings screen appears to have no consequence, while recipients can only be added, never removed.

Versions

core-api 1.6.62 (Fleetbase v0.7.63); same code in 1.6.61.

Suggested fix

Resolve the company from the subject passed in $params (e.g. its company_uuid) and read company.<uuid>.notification_settings directly, falling back to the session only when the subject carries no company.

Note

notifyUsingDefinitionName() nearby reads Setting::lookup('notification_settings') — the global key, with no company prefix — which looks like a separate inconsistency.