Sulu cache invalidation ambiguity for custom content types

Short answer

Sulu does not ship automatic invalidation rules for custom content types introduced through the REST API. The default caching layer (Symfony's cache component) only knows how to invalidate what it has been told about. To purge cached content reliably when a custom schema changes, you implement your own invalidation: tag your cached responses at write time and invalidate those tags explicitly, driven by Symfony kernel events or Doctrine lifecycle callbacks. There is no documented Sulu hook that guarantees cache clearing for arbitrary custom repository operations.

Likely explanation vs. confirmed facts

Confirmed by behavior of the building blocks: Symfony's cache supports tag-based invalidation (CacheTagsInvalidator), and Sulu's content layer builds cache keys that incorporate locale and, for versioned content, version state. If your custom type bypasses Sulu's own document/PHPCR write path, none of Sulu's built-in invalidation applies to it.

Likely, but version-dependent: the exact event names and service tags available for attaching listeners differ across Sulu releases, and the Symfony 6.4 / PHP 8.3 support line may change event availability or tag handling. Treat any specific event class name as something to verify against your installed version rather than as a stable contract.

Recommended approach

1. Tag every cacheable response your custom type produces, using tags that encode the schema identity, locale, and version state, e.g. mytype_schema_v3, locale_de.
2. Invalidate on schema change: register a listener on the event your REST schema-update path actually dispatches (a Doctrine postUpdate/postFlush on the schema entity is the most dependable option for custom types) and call the tag invalidator there.

use Symfony\Component\Cache\Adapter\TagAwareAdapterInterface;
use Symfony\Contracts\Cache\TagAwareCacheInterface;

final class SchemaChangeCacheInvalidator
{
    public function __construct(private TagAwareCacheInterface $cache) {}

    public function onSchemaUpdated(string $schemaTag): void
    {
        $this->cache->invalidateTags([$schemaTag]);
    }
}

Versioned and multilingual content

Because Sulu's cache keys incorporate locale prefixes and version identifiers, a schema change must invalidate across the full language fallback chain, not just the edited locale. Tag with the schema identity rather than a single locale, and invalidate that tag so all locale- and version-keyed entries derived from the old schema are dropped together. If you cache per-version snapshots, include the version identifier in the tag as well.

Verify against your installation

php bin/console debug:container --tag=cache.clearer
php bin/console debug:event-dispatcher

Then perform a REST schema update and confirm the relevant keys disappear (via cache:pool:clear in verbose mode or an APCu dump). One detail that changes this recommendation: which Sulu version you run, since listener signatures and available clearer services are not stable across releases.