auditor 4.2.0

✨ What's new

Support for long-running processes (Symfony Messenger workers)

When using auditor inside Symfony Messenger workers, only the first message was audited
correctly. Subsequent messages silently failed because the DoctrineSubscriber held a stale
EntityManager reference after reset, and DoctrineProvider reused cached PreparedStatement
objects bound to a closed connection.

DoctrineProvider now implements Symfony\Contracts\Service\ResetInterface. Its reset()
method clears the prepared statement cache and resets all subscriber transaction caches,
ensuring clean state between messages.

DoctrineSubscriber now retrieves the EntityManager directly from event arguments
(OnFlushEventArgs, LifecycleEventArgs) instead of relying on a constructor-injected
reference that could become stale.

Wiring kernel.reset in Symfony

Tag DoctrineProvider with kernel.reset so that Symfony's services_resetter calls
reset() automatically between messages:

# config/services.yaml
services:
    DH\Auditor\Provider\Doctrine\DoctrineProvider:
        tags:
            - { name: kernel.reset, method: reset }

If your service definition uses autoconfigure: true, Symfony detects ResetInterface
and registers the tag automatically — no additional config needed.

What's Changed

Bug fixes

• fix: support long-running processes (Messenger workers) by @Spomky in #307

References

• auditor-doctrine-provider
• Official documentation

Full Changelog: 4.1.0...4.2.0