-
-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: PHP Fatal error: Nesting level too deep - recursive dependency? #32432
Comments
Could it be, that this is already part of 24.0.2? |
Looks like the version from 24.0.2 differs in the following way:
|
This issue seems still present when creating a user present in a group and with mail and display name:
|
As additional information, it was working in 22.2.5, not anymore in 22.2.7 and above. |
I just tried this patch on our installation, but unfortunately this did not fix the issue. Still got the "Nesting level too deep" fatal error when creating a new user with group membership, just on line 213 instead of 212 now. |
With 2k issues in the pipe, what's the chance to get this one addressed soon? I can understand that it's not the highest priority as it's not blocking or security related. But it's seriously impacting the use of the whole system. |
This comment was marked as outdated.
This comment was marked as outdated.
After migrating from 23 to 24.0.3 I encountered a similar error while logging in (same error with local NC IDs and LDAP IDs) but with another line number: Aug 10 06:57:55 lxcloudp01 Nextcloud[18323]: {"reqId":"S3Q0cyy8kiY2fwkMF2CM","level":3,"time":"2022-08-10T06:57:55+02:00","remoteAddr":"10.100.41.137","user":"-ser-","app":"PHP","method":"POST","url":"/index.php/login","message":"Nesting level too deep - recursive dependency? at /srv/www/htdocs/owncloud/lib/private/Log/ExceptionSerializer.php#215","userAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0","version":"24.0.3.2","data":{"app":"PHP"}}[Wed Aug 10 06:53:02.096193 2022] [php7:error] [pid 18300] [client 10.100.41.137:65027] PHP Fatal error: Nesting level too deep - recursive dependency? in /srv/www/htdocs/owncloud/lib/private/Log/ExceptionSerializer.php on line 215 I think this is the same error, isn't it? Would try to migrate to a stable version where it is fixed. And one question: The program affected is ExceptionSerializer. I don't understand it's job, so I wonder if this Nesting level too deep the only error or does it occur while catching another error of another module? |
Hi I tried to patch but looks like the code already changed a lot in ExceptionSerializer.php (we're still running on 22.2.7, and I was waiting for a fix before my next update).
Could you confirm that changes would be compatible with our installed version if:
Thanks ! |
I'm unable to reproduce with latest master branch. |
I can reproduce with the Docker image. I'll see if that is debuggable. |
I did find out that disabling the app |
Jepp ... disabling |
@ArtificialOwl could you have a look at #32432 (comment)? Maybe we can break the recursive structure. Otherwise I suggest dropping the |
Excellent !! Thank you for the debugging 👍 |
I hit this with the Docker image as well when upgrading to Nextcloud 25.0.0. |
Same behavior here when upgraded to 25 from docker img ver 24. |
this was supposed to be fixed, do you have more logs available ? |
Sure thing. Here's from my Nextcloud.log, you can see the update process finish and then just 22 seconds later a client checks in and gets the issue:
Same time frame, this time from NGINX's perspective:
My currently installed version of Circles is 25.0.0. From what I can tell, these issues occurred during every PROPFIND request after the upgrade process from my Mac and iOS clients until I disabled the Circles app. That was a few hours ago when I found this thread; no errors since. This user is a member of two groups. |
Do you still have error if running (first):
then try to enable the Circles app again ?
|
I think this will be the next step. |
@ArtificialOwl this does not work for me. I think it's because the value is checked for empty here: route_to_circle . Worarounds that work for me
Sideeffects for the workarounds
Some technical backgroundThe trace, like I observed it, is the following:
What needs to be fixed/implemented (IMO)In the In NC core: check if there is a way to circumvent that (recursive) objects are passed inside the array of |
In our case, "Contacs" is enabled since it's the UI for managing Circles since NC 21 (or 22?) Otherwise, there are some outdated Apps (witeboard e.g.) placed in config.php within the array app_install_override and are not installed after the update. Since I restored the old config.php when rolling back the failed upgrade, I can't see if it was like this with Contacts App. It might have possibly happened with contacts in case there was just some foobar version problem on 2022-08-09 when I tried to upgrade. So far it would be obvious why I couldn't reproduce the error. I just disabled Contacts in our stageing environment and got the error. I think it's getting clearer what happend and how to prevent it. |
Yes, you are right; but how was it working before ?... Next release should avoid calling this method when generating an exception, but I will see to add a check on the availability of the app before generating the url from the route. Thanks for your deep report |
Well, that's a question I cannot answer directly. The only thing that I can tell is, that for example on my DEV machine I cannot reproduce the error even when trying to replicate my PROD setup. Could imagine that it somehow depends on how exactly the arguments/objects inside of Generally speaking: when fixing the log problem inside the |
Same here, but I also didn't check for activated/updated/deactivated Apps after the error occurred since I had to bring the live system online again. If I had any hint which App might be the source of the error I would have checked it on CLI. |
Had this error when logging in (instead of being logged in, getting a 500 and blank page) with a 25.0.1 instance, no special configuration, and disabling the Circles app made it work again. Did not debug it further than that. |
Updating from 24.0.2 to 24.0.7 likely caused this on our instance. We use LDAP as a user backend, along with a group added to all users by default. Disabling circles did help as a workaround. Maybe helpful also, it didn't affect my account, one of the first on the instance, but it did accounts that never logged in before or perhaps newer than some date. I haven't established what's the oldest account affected, and it's likely impossible now. |
+1 on Nextcloud 25.0.2 |
Also had this issue when logging in, getting a 500 and blank page, on a NC23 docker instance after an upgrade from a NC22, then again on a NC24.0.8 after trying to just upgrade my way past it. Then again on NC25.0.2 which I tried just for fun. I found this thread and disabled circles and I could log in again for each NC24 and NC25. Hopefully someone will understand what causes this and can help get it sorted. For now I'll just keep circles disabled I guess. My log showed |
Just for the record, this is not just related to #23429, this issue is a duplicate of #23429. It's the same issue with just a different error message. The cause of this is a bug in Simplest solution is to limit recursion depth. Since we're talking about an exception serializer whose job is to process exceptions for human display, we don't need arbitrary deep stack traces anyway... The funny thing is: Calling I was just thinking about an quick fix, but honestly, Just for the record: PHP now comes with native support to redact sensitive information from stack traces in a cradle to grave approach. See https://php.watch/versions/8.2/backtrace-parameter-redaction. Even though this is also possible without native support (requires to wrap any sensitive information into objects, but also requires to change how this sensitive information is used elsewhere), it makes things way easier. When Nextcloud drops support for PHP 8.1 and earlier, we should think about using PHP's new native feature insead. |
FYI I just upgraded to NC 25.0.2 and experienced this error. The workaround of disabling the circles app via CLI solved the issue. |
Feel free to try #35970 |
Applied the patch from the first commit of the mentioned PR
For me the error has gone after patching, thank you @juliushaertl ! Note: I also noticed that the error just occures sometimes on my system (so I cannot reproduce the error constantly). So a few other testers would definately make sense 👍 |
I noticed this being caused by a info log message (that was not logged in my logs) but caused the error and then the failure. For my case was caused by nextcloud/circles#1233 which also only happened from time to time due to caching being in place for the router. |
Thanks for the hint! Would really be great to have a sample Exception/message which causes the problem. A testcase could then proove that this won't happen again. Already tried to construct such a thing but with no luck so far 😢 |
I had the same issue, but only the calendar and file dav sync did not work anymore. Webinterface worked fine for me. Disabling Circles fixed it. If I had known the issues with circles, I would not have upgraded, or if circles would have marked as incompatible this would have saved me some trouble (v25.0.2) |
Had the same issue when upgrading from 24 to 25. Disabling the app Circles fixed the problem for the moment. |
Closing as #35970 was merged and the fix itself back ported for the next 24/25 maintenance release. |
So the fix is to come with |
Hi, Got the same error when user logged in. The issue was two-factor authentification. When I user is created without TOTP enable and then you add group user to force TOTP this error happen : PHP Fatal error: Nesting level too deep - recursive dependency? Looks like when we force user or group after user creation it create this error. My fix :
Hope this help ! |
I just had the same error. |
I can confirm everything from @TheIceMagmaCube. Same is true for me. |
Couldn't you just disable the Circles app? |
Oh, I misread the comment. In my case, disabling the Circles app actually did the trick. |
If possible, please update to the latest Nextcloud version |
Bug description
When creating a user which is part of any group, there is an error thrown in the UI: "An error occurred during the request. Unable to proceed.".
nextcloud.log
hasPHP Fatal error: Nesting level too deep - recursive dependency? in /var/www/html/lib/private/Log/ExceptionSerializer.php on line 212
.Creating a user without being part of a group works as expected.
If you try this again, this fails cause the user is already present. Reloading the page you see the user and it's part of the group, but any other user information is missing.
See this on a new instance of latest 22.x, 23.x and 24.0. With 21.x and below we do not face this issue.
Steps to reproduce
Expected behavior
Created user with details when user is part of a group when creating.
Installation method
Other
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.0
Web server
Nginx
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Updated to a major version (ex. 22.2.3 to 23.0.1)
Are you using the Nextcloud Server Encryption module?
No response
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
This seems also be an issue with the official helm chart. The suggested dirty fix in pulsejet/nextcloud-oidc-login#133 (comment) seems also work for us.
It might also be related to #23429 (comment)
The text was updated successfully, but these errors were encountered: