In context of the
API Toolkit module →
, I'm using the AtLeastOneOf Symfony validator constraint to validate a request property. The API Toolkit uses the Drupal constraint validator, which uses its own implementation of Symfony\Component\Validator\Context\ExecutionContextInterface. This implementation is missing a simple fix that was added to \Symfony\Component\Validator\Context\ExecutionContext in this commit, causing the AtLeastOneOf constraint to not work.
Create a API Toolkit request class, inject it in a controller function argument and visit the API endpoint with 2024-01-26T10:31:42.144Z as startDate. The validation will not pass, even though it should.
<?php
namespace Drupal\mms_app_v2\Request;
use Drupal\api_toolkit\Request\ApiRequestBase;
use Symfony\Component\Validator\Constraints as Assert;
class CreateActivityRequest extends ApiRequestBase
{
/**
* @Assert\AtLeastOneOf({
* @Assert\DateTime(format = \DateTime::RFC3339),
* @Assert\DateTime(format = \DateTime::RFC3339_EXTENDED),
* })
*/
public string $startDate;
}
<?php
namespace Drupal\mms_app_v2\Controller;
use Drupal\mms_app_v2\Request\CreateActivityRequest;
use Symfony\Component\HttpFoundation\Response;
class CreateActivityController
{
public function __invoke(CreateActivityRequest $request): Response
{
return new Response(status: Response::HTTP_NOT_IMPLEMENTED);
}
}
Add the __clone method to ExecutionContext.
Active
11.0 🔥
Never mind, seems like Symfony\Component\Validator\Context\ExecutionContext is being used after all and I just need to backport the fix there. I don't think Drupal\Core\TypedData\Validation\ExecutionContext is being cloned anywhere at this point, so it's not really absolutely necessary to fix this. I'll keep the issue open for now in case we do want to fix it, it's not that big of a change after all.