It doesn't appear to be reserved/disallowed by Drupal or Symfony - this works fine for me in 9.3.13 after adding the code and rebuilding cache (no extra steps):
custom_module.services.yml
services:
custom_module.event_subscriber:
class: Drupal\custom_module\EventSubscriber\XYZFeeds
tags:
- { name: event_subscriber }
src/EventSubscriber/XYZFeeds.php
<?php
namespace Drupal\custom_module\EventSubscriber;
use Drupal\Core\Config\ConfigCrudEvent;
use Drupal\Core\Config\ConfigEvents;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
class XYZFeeds implements EventSubscriberInterface {
public static function getSubscribedEvents() {
return [
ConfigEvents::SAVE => 'configSave',
ConfigEvents::DELETE => 'configDelete',
];
}
public function configSave(ConfigCrudEvent $event) {
$config = $event->getConfig();
\Drupal::messenger()->addStatus('Saved config: ' . $config->getName());
}
public function configDelete(ConfigCrudEvent $event) {
$config = $event->getConfig();
\Drupal::messenger()->addStatus('Deleted config: ' . $config->getName());
}
}
This produces the expected messages on config save/delete, so it seems likely your problem is something more localised.
One idea for further debugging that springs to mind is to check that you have no custom (or even contrib) code which is altering the service, perhaps even removing it. This can be done using a service provider, so grep-ing the relevant folders for ServiceProvider
might be a first step.
It would also be worth a test to change the first part of the ID rather than the second, to see if is indeed event_subscriber
that's causing the problem, or the string as a whole:
services:
my_module_test.event_subscriber:
class: Drupal\my_module\EventSubscriber\XYZFeeds
tags:
- { name: event_subscriber }
If the altered version works with .event_subscriber
, at least you've ruled that out as the problem.