SF 5.2 doctrine/persistence #38694
Comments
|
Hey. Are you saying that you get an error from a symfony class because you are missing |
|
Error list: |
|
Thank you. Can you also show me a stack trace? |
|
I managed to reproduce one. |
|
For completed : If it can help |
|
Could you please create a small example application that allows to reproduce your issue? |
|
I've seen this too on 5.1. It is related to doctrine annotations I think. But I've never been able to reproduce it. I've only seen in in production logs... |
|
I cannot reproduce the bug on the test application. I will see to provide you with that this weekend. I have the bug on my application but not on the test. I'll do a toggle and provide you with the basics of the bugging app. |
|
I only copy my vendor folder, the files from the Entity folder and Repository. By repeating the test, the bug reproduces well on my side. Include vendor folder in the git : https://github.com/wolpheus/sftest Edit : Link -> reset-password |
|
Following the various tests, to resolve the problem apparently would be to delete the vendor folder and do a composer install to put everything back. The bug no longer occurs afterwards. Edit : 31/10 : The problem is always present. |
|
I think I have found, the problem comes from cleaning the cache after the passage of composer. You have to do a clean cache so that everything comes back in place. Now I don't know why. |
|
@Wolpheus I am not sure if I were able to follow this completely. Do you mean that the issue is gone when you fully clear the cache of your application? |
|
Yes, I clean the cache it works well, I do a composer update I end up with these errors, I have to reset the cache. |
|
Looks like there is nothing to do then. Thank you for the confirmation. |
|
I am also seeing this issue on my User class, but it only happens when the cache has been fully warmed up (and somehow only on the prod machine, I can not repro this locally). If I I believe this started happening since I added the two custom constraint annotations. Here the stack trace: And the info I could extract from
So it appears the cache warmup fails to find the annotations or something, dumps a null in cache, and then the cached annotation reader returns null and that does not work. I'm not entirely sure what else to look at here. The cache warmup process isn't something I'm very familiar with. |
|
Alright after a lot of trial and error commenting out random bits of code.. I narrowed it down to this: an entity with: And the smallest custom constraint which triggers the issue: <?php
namespace App\Validator;
use Symfony\Component\Validator\Constraints\Compound;
use Symfony\Component\Validator\Constraints as Assert;
use Symfony\Component\Validator\Context\ExecutionContextInterface;
/**
* @Annotation
*/
class CustomConstraint extends Compound
{
protected function getConstraints(array $options): array
{
return [
new Assert\Callback(function ($value, ExecutionContextInterface $execContext): void {
})
];
}
}It appears the Assert\Callback does not play well somehow with the cache warming. Once this is in place, running the following triggers the error (first warmup works, second run fails while loading the cache): I hope this helps someone else figure out what the issue is. If Callback constraints can not be used in Compound ones or maybe do not play well with the cache warmer on their own (not sure if related to Compound), then it should ideally fail earlier and more explicitly than the current runtime corruption. If they can be made to work that'd be even better. As a workaround I guess I will convert my callback constraint to a real constraint, it was mostly laziness that lead me there. I'm curious if @Bleizstudio was also using a Callback? |
|
Thank you @Seldaek I created a small reproducer here: https://github.com/Nyholm/sf-issue-38694 I found the issue and added a patch. See #40645. |
|
@Seldaek Hi, Honestly, I have changed my code so much, done tests that I don't know what I was doing. One thing is certain is that it was indeed the User class that was impacted. Anyway congratulations on finding, I don't know enough about Symfony in its design to allow me to have a problem-solving guess. Thank you for being able to push things further :) |
…pter (nicolas-grekas) This PR was merged into the 4.4 branch. Discussion ---------- [Cache] skip storing failure-to-save as misses in ArrayAdapter | Q | A | ------------- | --- | Branch? | 4.4 | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | Fix #38694 | License | MIT | Doc PR | - In addition to #40645 Commits ------- ba66987 [Cache] skip storing failure-to-save as misses in ArrayAdapter
This PR was squashed before being merged into the 4.4 branch. Discussion ---------- [FrameworkBundle] Dont store cache misses on warmup | Q | A | ------------- | --- | Branch? | 4.4 | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | Fix #38694 | License | MIT | Doc PR | symfony/symfony-docs#15172 When we are warming the annotation cache, we are reading all annotation into an `ArrayAdapter`. When we are done we move the values to a `PhpArrayAdapter` to store them in a file. @Seldaek [found out](#38694 (comment)) that when you are using a custom constraint with a `Symfony\Component\Validator\Constraints\Callback`, there is a strange error like: > Can use "yield from" only with arrays and Traversables That is because the `Closure` in the `Symfony\Component\Validator\Constraints\Callback` cannot be serialised and saved to cache. But since the `ArrayAdapter` is also [storing misses as null](#35362), the null values are understood as real values. When all values are moved to the `PhpArrayAdapter` and we ask the cache for a value (via Doctrine's `CacheProvider`), it will return `null` as a value instead of `false` as a cache miss. And `null` is not something one could "yield from". Commits ------- 27a22b3 [FrameworkBundle] Dont store cache misses on warmup
This PR was squashed before being merged into the 4.4 branch. Discussion ---------- [FrameworkBundle] Dont store cache misses on warmup | Q | A | ------------- | --- | Branch? | 4.4 | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | Fix #38694 | License | MIT | Doc PR | symfony/symfony-docs#15172 When we are warming the annotation cache, we are reading all annotation into an `ArrayAdapter`. When we are done we move the values to a `PhpArrayAdapter` to store them in a file. @Seldaek [found out](symfony/symfony#38694 (comment)) that when you are using a custom constraint with a `Symfony\Component\Validator\Constraints\Callback`, there is a strange error like: > Can use "yield from" only with arrays and Traversables That is because the `Closure` in the `Symfony\Component\Validator\Constraints\Callback` cannot be serialised and saved to cache. But since the `ArrayAdapter` is also [storing misses as null](symfony/symfony#35362), the null values are understood as real values. When all values are moved to the `PhpArrayAdapter` and we ask the cache for a value (via Doctrine's `CacheProvider`), it will return `null` as a value instead of `false` as a cache miss. And `null` is not something one could "yield from". Commits ------- 27a22b34af [FrameworkBundle] Dont store cache misses on warmup
Symfony version(s) affected: 5.2
Description
Hi,
Just to point out that with each update of 5.2 via composer, I am forced after to redo a composer req doctrine/persistence, otherwise I have errors with the default user registration system. The login is fine, but each time it has an impact on the registration and the lost password.
How to reproduce
composer update
I suspect updating dbal
Possible Solution
composer req doctrine/persistence
Additional context
If needed at the next update
The text was updated successfully, but these errors were encountered: