Do not run CatchUpSubscriptionEngine for _wdt and _profiler requests

[fritz-gerneth]

Would it make sense to not run the in these kind of requests for the Profiler UI and requests related to the toolbar?

• When a subscription fails the error blocks requests (and therefore) access to the profiler or requests related to the wdt
• When the subscription catches up, makes it hard to trace the request where this actually happend, as this could happen in a request related to the wdt/profiler (e.g. when we want to look at the profiled data for a caught up run)

I would suggest to not run the catchup engine when detecting either kind of request. Not sure though what the best way would be do so (except matching url prefix, but that seems wonky)

[DavidBadura]

It makes perfect sense that the Subscription Engine is not running in Profiler/Toolbar requests. However, CatchUpSubscriptionEngine is not directly related to this. Our RequestListeners are most likely the trigger:

https://github.com/patchlevel/event-sourcing-bundle/tree/3.15.x/src/RequestListener

Have you enabled auto_setup or rebuild_after_file_change in your environment?

Instead of checking the URL, you can also check the route name. That should be more stable.

[fritz-gerneth]

Have you enabled auto_setup or rebuild_after_file_change in your environment?

Yes

Instead of checking the URL, you can also check the route name. That should be more stable.

Thought about this as well. However, this is quite a list of route names:

4	_wdt_stylesheet	/_wdt/styles	Path does not match
5	_wdt	/_wdt/{token}	Path does not match
6	_profiler_home	/_profiler/	Path does not match
7	_profiler_search	/_profiler/search	Path does not match
8	_profiler_search_bar	/_profiler/search_bar	Path does not match
9	_profiler_phpinfo	/_profiler/phpinfo	Path does not match
10	_profiler_xdebug	/_profiler/xdebug	Path does not match
11	_profiler_font	/_profiler/font/{fontName}.woff2	Path does not match
12	_profiler_search_results	/_profiler/{token}/search/results	Path does not match
13	_profiler_open_file	/_profiler/open	Path does not match
14	_profiler	/_profiler/{token}	Path does not match
15	_profiler_router	/_profiler/{token}/router	Path does not match
16	_profiler_exception	/_profiler/{token}/exception	Path does not match
17	_profiler_exception_css	/_profiler/{token}/exception.css	Path does not match

Keeping this in sync with what routes the profiler / toolbar have will be a bit of work. Though this could be extended into a config option of routes to exclude in general (and add our own routes maybe). Or some callback to decide if to run (though again this would need to be chainable or some event)?

[DavidBadura]

I see two possibilities:

Either we hardcode it on a route basis. In that case, I would only check the prefixes of the routes:

 if (!$event->isMainRequest()) {
    return;
}

$request = $event->getRequest();
$route = $request->attributes->get('_route') ?? '';

if (str_starts_with($route, '_profiler')
    || str_starts_with($route, '_wdt')
    || str_starts_with($route, '_error')
) {
    return;
}

Or the flexible version, which you already suggested and my favorite, making it configurable but on a URL basis. Similar to how the security firewall works:

security:
    firewalls:
        dev:
            pattern: ^/(_(profiler|wdt)|css|images|js)/
            security: false

The config could look like this:

patchlevel_event_sourcing:
    subscription:
        auto_setup:
            allowed_urls: ^/(?!_(wdt|profiler|error)) # default
        rebuild_after_file_change: true
            allowed_urls: ^/(?!_(wdt|profiler|error)) # default