The second solution is better but means you cannot enable cache if using SonataAdminBundle (see code)?

Why not having two different constraint containers :

• The cacheable one with serializable constraints (coming from configuration: YAML, Annotation ...). All constraints from configuration are serializable because they have no context ($this) and cannot contain a Closure.
• The not-cached one with constraints instantiated in user code. I can't see the interest of caching these ones.

GenericMetadata::$constraints = [];
GenericMetadata::$notCacheableConstraints = [];

GenericMetadata::addConstraint(Constraint $constraint)
{
    if ($constraint->isSerializable()) {
        $this->constraints[] = $constraint;
    } else {
        $this->notCacheableConstraints[] = $constraint;
    }
    // ...
}

The second solution is better but means you cannot enable cache if using SonataAdminBundle

That's not true. getMetadataFor() already returns the cached metadata. If you add a constraint in this way, that constraint is not going to be cached.

Yes indeed, but the error is raised when trying to get metadata for a class (like a Doctrine proxy: #10083) inheriting from another one containing constraint (with Closure).

// You have these classes
class Item {}
class SubItem extends Item {}

$metadata = getMetadataFor(Entity\Item); // OK returns the metadata (written to the cache)
$metadata->addConstraint(new Callback(Closure));

getMetadataFor(Entity\SubItem); // KO Tries to cache the parent class also and hits the Closure

I see, thanks for the clarification! This should indeed be fixed.

See #20740 for a possible fix

I'm closing this one, because #20793 fixes the Symfony related part, and the remaining part is fixed by using Symfony Cache, which handles serialization failures properly (no exception, no write).