LogsActivity listeners disappear under Octane after model listeners are flushed & re-observed; no activities are written

[somarkn99]

Package & stack:

• spatie/laravel-activitylog
• Laravel: 12
• PHP: 8.3.26
• DB: PostgreSQL
• Runtime: Laravel Octane (RoadRunner/Swoole) in Docker
• OS: Ubuntu (container)

Summary

On local (plain PHP-FPM / artisan serve) activity logs are written as expected.
On production under Octane, models that we rebind observers for stop producing activity log entries even though Eloquent model events (created, updated, deleted) still fire.

It looks like listeners registered by Spatie\Activitylog\Traits\LogsActivity are being removed and not consistently re-attached in Octane workers after we call Model::flushEventListeners() to avoid double-firing across long-lived workers.

What we do (Octane worker rebind)
Because our app uses many observers and we run under Octane, we rebind them per worker to avoid stale listeners:

// AppServiceProvider.php (excerpt)
private function resetDispatcherAndRebindObservers(string $source): void
{
    // 1) restore dispatcher
    Model::setEventDispatcher(app('events'));

    // 2) allow models to boot again in this worker
    Model::clearBootedModels();

    // 3) rebind for each model we manage
    foreach (self::OBSERVER_MAP as $model => $observers) {
        // remove previous listeners to avoid duplicates
        $model::flushEventListeners();

        // force the model to boot so trait/package listeners attach again
        new $model();

        // attach our observers
        foreach ($observers as $observer) {
            $model::observe($observer);
        }
    }
}

We also tried the simpler variant (flush + observe, without new $model()), and the problem persists.
LogsActivity registers its event listeners again once the model is (re)booted in the worker, so activities keep being recorded after created/updated/deleted.

flushEventListeners() clears the listeners that LogsActivity added via registerModelEvent(…). Under Octane, even after Model::clearBootedModels() and re-instantiating the model, those listeners are not re-registered consistently (possibly due to boot state caching or interaction between flushEventListeners() and the trait’s boot method). The net result: the package’s listeners are missing for the remainder of the worker lifetime.

Is LogsActivity expected to survive Model::flushEventListeners() + re-boot in long-lived Octane workers?

Is there a supported way to re-attach the package’s listeners after we flush model listeners per worker?

If the trait keeps internal state to avoid double registration, can it be safely reset when clearBootedModels() is called?