[loevgaard]

Closes #17.

The review of #12 and #13 found these bugs in code that those PRs don't change, so they get their own PR.

Empty and overlong client ids

RequestBasedCookieProvider accepted any client id that Cookie::fromString() returned:

• 2.1.1. gave an empty client id, so every visitor with such a cookie shared one client and one metadata row.
• A client id longer than the 255 characters of the clientId column was accepted. As A client id longer than 255 characters makes requests that write metadata fail on MySQL and PostgreSQL #17 describes, every request that wrote metadata for that visitor then failed with a 500 on MySQL and PostgreSQL.

The provider now treats both as no cookie, so the visitor gets a new client id and a new cookie.

Looking up the entity manager lazily

DoctrineOrmBasedMetadataProvider looked up the entity manager of the metadata class when it created the lazy metadata. getManagerForClass() initializes the entity manager and asks its metadata factory about the class, so every request with a cookie did that, even when the application never used the metadata. The lookup now happens in the lazy ghost's initializer.

Not in this PR: the closed entity manager after a lost insert race

The review also found that the persister leaves the entity manager closed after it swallows a UniqueConstraintViolationException (#5). I first reset the manager through the registry, but reverted that: with Symfony 7.0 and ORM 3, the reset turns the entity manager back into an uninitialized lazy ghost, and initializing it again fails on ORM's readonly properties (Cannot modify readonly property Doctrine\ORM\EntityManager::$conn). The manager is then unusable, which is worse than closed. Writing the row with DBAL instead of flush(), as #16 suggests, keeps the manager open without a reset.

Tests

• Unit tests for an empty client id, and for client ids of 255 and 256 characters. A functional test checks that a visitor with an empty client id gets a new one.
• it_returns_lazy_metadata asserts that the provider doesn't look up the manager before the metadata is used.

Testing

• PHPUnit: 105 tests pass on PHP 8.4 with Symfony 7.4, rebased on master with Fix configuring a metadata class that extends the bundle's Metadata #14 and Reset the cached client between requests and key the cookie cache by request #15. They also pass with the lowest dependencies installed like CI does, on PHP 8.1 with Symfony 6.4 and on PHP 8.2 with Symfony 7.0
• PHPStan, ECS and composer-dependency-analyser pass
• Infection: 89 of 89 mutants killed

Stack

PRs that add tests to the bundle and fix what the tests and their review found. #12 to #15 are merged, and #20 builds on master.

1. Move the tests into tests/Unit and add missing unit tests #12 (merged): move the existing tests into tests/Unit and add the unit tests that were missing
2. Add functional tests that run the bundle with a database #13 (merged): functional tests that run the bundle in a Symfony application with a database
3. Fix configuring a metadata class that extends the bundle's Metadata #14 (merged): fix a custom metadata_class that extends the bundle's Metadata, found by the functional tests
4. Reset the cached client between requests and key the cookie cache by request #15 (merged): reset the cached client between requests in long-running runtimes, and key the cookie cache by request, found by the functional tests
5. Reject unusable client ids and look up the entity manager lazily #20: reject unusable client ids and look up the entity manager lazily, found in the review of Move the tests into tests/Unit and add missing unit tests #12 and Add functional tests that run the bundle with a database #13