This is potentially fixed with 891c10d @waja could you try to patch your server with this patch and confirm?

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:

--- ExceptionSerializer.php.24.0.2	2022-06-20 17:01:33.000000000 +0200
+++ ExceptionSerializer.php	2022-06-21 17:06:01.668852037 +0200
@@ -42,8 +42,6 @@
 use OCP\HintException;
 
 class ExceptionSerializer {
-	public const SENSITIVE_VALUE_PLACEHOLDER = '*** sensitive parameters replaced ***';
-
 	public const methodsWithSensitiveParameters = [
 		// Session/User
 		'completeLogin',
@@ -182,7 +180,7 @@
 		if (isset($traceLine['args'])) {
 			$sensitiveValues = array_merge($sensitiveValues, $traceLine['args']);
 		}
-		$traceLine['args'] = [self::SENSITIVE_VALUE_PLACEHOLDER];
+		$traceLine['args'] = ['*** sensitive parameters replaced ***'];
 		return $traceLine;
 	}
 
@@ -213,7 +211,7 @@
 		$workArgs = [];
 		foreach ($args as $arg) {
 			if (in_array($arg, $values, true)) {
-				$arg = self::SENSITIVE_VALUE_PLACEHOLDER;
+				$arg = '*** sensitive parameter replaced ***';
 			} elseif (is_array($arg)) {
 				$arg = $this->removeValuesFromArgs($arg, $values);
 			}

This issue seems still present when creating a user present in a group and with mail and display name:

{"reqId":"spSXyDTGLqAu7cnpKZk6","level":3,"time":"2022-06-21T15:21:06+00:00","remoteAddr":"172.19.0.2","user":"admin","app":"PHP","method":"POST","url":"/ocs/v2.php/cloud/users","message":"Nesting level too deep - recursive dependency? at /nextcloud/lib/private/Log/ExceptionSerializer.php#213","userAgent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.61 Safari/537.36","version":"24.0.2.1"}

As additional information, it was working in 22.2.5, not anymore in 22.2.7 and above.
If not possible to revert to code from previous version, is there any upgrade path that would solve that issue?

This is potentially fixed with 891c10d @waja could you try to patch your server with this patch and confirm?

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.
Is there really people creating users without any group? Also users set as admin for a group doesn't have the choice, new users that they create, always come with that group assigned.

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?

My attempt at fixing this: #33501

You can download it as patch from https://patch-diff.githubusercontent.com/raw/nextcloud/server/pull/33501.patch. Patching instructions can be found here: https://docs.nextcloud.com/server/latest/admin_manual/issues/applying_patch.html. Let me know if this improves anything.

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).

patch -p 1 < /home/test/nextcloud/33501.patch patching file lib/private/Log/ExceptionSerializer.php Hunk #1 FAILED at 40. Hunk #2 FAILED at 210. 2 out of 2 hunks FAILED -- saving rejects to file lib/private/Log/ExceptionSerializer.php.rej

Could you confirm that changes would be compatible with our installed version if:

• add Hunk1 to the use

• replace whole content of function removeValuesFromArgs($args, $values) with only the + of Hunk2
  ` private function removeValuesFromArgs($args, $values) {
  return array_map(function($arg) use ($values) {
  // Sensitive?
  try {
  if (in_array($arg, $values, true)) {
  return self::SENSITIVE_VALUE_PLACEHOLDER;
  }
  } catch (Throwable $e) {
  // In very rare cases PHP can't run in_array on the args because
  // of a recursive structure. In that case we fall back to
  // assuming the argument could be sensitive
  return self::SENSITIVE_VALUE_PLACEHOLDER;
  }

    	// Array?
    	if (is_array($arg)) {
    		return $this->removeValuesFromArgs($arg, $values);
    	}
  
    	return $arg;
    }, $args);
  

  }
  `

Thanks !

Steps to reproduce

1. Login to Nextcloud instance with privileged account

2. Navigate to /settings/users

3. Click on "New User"

4. Fill in the users information including e-mail, password, group (this is important to trigger the bug) and display name

5. Click "Add new user"

6. Error appears on the upper right corner: "An error occurred during the request. Unable to proceed."

7. Refresh webpage

I'm unable to reproduce with latest master branch.

I can reproduce with the Docker image. I'll see if that is debuggable.

1. \OCA\Provisioning_API\Controller\UsersController::addUser runs until $this->groupManager->get($group)->addUser($newUser);.
2. \OC\Group\Group::addUser runs until $this->emitter->emit('\OC\Group', 'postAddUser', [$this, $user]);
3. From there it gets messy as there are many hooks and listeners for the event.
4. \OCA\Circles\Listeners\GroupMemberAdded::handle runs until $this->syncService->groupMemberAdded($group->getGID(), $user->getUID());
5. \OCA\Circles\Service\SyncService::groupMemberAdded runs until $this->federatedEventService->newEvent($event);
6. \OCA\Circles\Service\FederatedEventService::newEvent runs until $this->initBroadcast($event);. At this point I see a diff between Nextcloud 24 and the master branch: enforce event on circle creation circles#1112
7. Looks like we go into https://github.com/nextcloud/circles/blob/c40fa11f21a7198f42e8bc7f48de73a795904342/lib/Service/FederatedEventService.php#L445 before the php process errors out hard. If I comment out the $wrapper argument logging works.
   7.1) It's possibly caused by Unable to generate a URL for the named route \"contacts.contacts.directcircle\" as such route does not exist. logged with the $wrapper object. My setups doesn't have Contacts enabled.

I did find out that disabling the app circles eliminates the bug. Could someone try and see if that helps your instance as well?

Could someone try and see if that helps your instance as well?

Jepp ... disabling circles eliminates the PHP Fatal error: Nesting level too deep - recursive dependency? problem on our instances.

@ArtificialOwl could you have a look at #32432 (comment)? Maybe we can break the recursive structure. Otherwise I suggest dropping the $wrapper object from being logged.

Excellent !! Thank you for the debugging 👍
Disabling "Circles" app indeed solves the issue here as well.

I hit this with the Docker image as well when upgrading to Nextcloud 25.0.0. occ app:disable circles fixed it as well for me.

I hit this with the Docker image as well when upgrading to Nextcloud 25.0.0. occ app:disable circles fixed it as well for me.

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:

{"reqId":"M5DMmmt53bmHVotmnrSt","level":1,"time":"2022-10-20T10:27:12+00:00","remoteAddr":"","user":"--","app":"updater","method":"","url":"--","message":"OC\\Repair\\Events\\RepairStepEvent: Repair step: Add token cleanup job","userAgent":"--","version":"24.0.6.1","data":{"app":"updater"}}

{"reqId":"M5DMmmt53bmHVotmnrSt","level":1,"time":"2022-10-20T10:27:12+00:00","remoteAddr":"","user":"--","app":"updater","method":"","url":"--","message":"OC\\Repair\\Events\\RepairStepEvent: Repair step: Clean up abandoned apps","userAgent":"--","version":"24.0.6.1","data":{"app":"updater"}}

{"reqId":"M5DMmmt53bmHVotmnrSt","level":1,"time":"2022-10-20T10:27:12+00:00","remoteAddr":"","user":"--","app":"updater","method":"","url":"--","message":"\\OC\\Updater::startCheckCodeIntegrity: Starting code integrity check...","userAgent":"--","version":"24.0.6.1","data":{"app":"updater"}}

{"reqId":"M5DMmmt53bmHVotmnrSt","level":1,"time":"2022-10-20T10:27:15+00:00","remoteAddr":"","user":"--","app":"updater","method":"","url":"--","message":"\\OC\\Updater::finishedCheckCodeIntegrity: Finished code integrity check","userAgent":"--","version":"24.0.6.1","data":{"app":"updater"}}

{"reqId":"M5DMmmt53bmHVotmnrSt","level":1,"time":"2022-10-20T10:27:15+00:00","remoteAddr":"","user":"--","app":"updater","method":"","url":"--","message":"\\OC\\Updater::updateEnd: Update successful","userAgent":"--","version":"25.0.0.18","data":{"app":"updater"}}

{"reqId":"M5DMmmt53bmHVotmnrSt","level":1,"time":"2022-10-20T10:27:15+00:00","remoteAddr":"","user":"--","app":"updater","method":"","url":"--","message":"\\OC\\Updater::maintenanceDisabled: Turned off maintenance mode","userAgent":"--","version":"25.0.0.18","data":{"app":"updater"}}

{"reqId":"M5DMmmt53bmHVotmnrSt","level":1,"time":"2022-10-20T10:27:15+00:00","remoteAddr":"","user":"--","app":"updater","method":"","url":"--","message":"\\OC\\Updater::resetLogLevel: Reset log level to Warning(2)","userAgent":"--","version":"25.0.0.18","data":{"app":"updater"}}

{"reqId":"U0VNPCruyE5MkNqPYtGG","level":3,"time":"2022-10-20T10:27:37+00:00","remoteAddr":"myIPAddr","user":"myUser","app":"PHP","method":"PROPFIND","url":"/remote.php/dav/files/myUser/","message":"Nesting level too deep - recursive dependency? at /var/www/html/lib/private/Log/ExceptionSerializer.php#215","userAgent":"Mozilla/5.0 (Macintosh) mirall/3.6.1git (build 11939) (Nextcloud, osx-21.6.0 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"25.0.0.18","data":{"app":"PHP"}}

{"reqId":"ZXF1H1AVri1VN4Aldgm6","level":3,"time":"2022-10-20T10:27:37+00:00","remoteAddr":"myIPAddr","user":"myUser","app":"PHP","method":"PROPFIND","url":"/remote.php/dav/files/myUser/","message":"Nesting level too deep - recursive dependency? at /var/www/html/lib/private/Log/ExceptionSerializer.php#215","userAgent":"Mozilla/5.0 (Macintosh) mirall/3.6.1git (build 11939) (Nextcloud, osx-21.6.0 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"25.0.0.18","data":{"app":"PHP"}}

{"reqId":"JK36xRDfqZYCUDRbnfNr","level":3,"time":"2022-10-20T10:29:41+00:00","remoteAddr":"myIPAddr","user":"myUser","app":"PHP","method":"PROPFIND","url":"/remote.php/dav/files/myUser/","message":"Nesting level too deep - recursive dependency? at /var/www/html/lib/private/Log/ExceptionSerializer.php#215","userAgent":"Mozilla/5.0 (Macintosh) mirall/3.6.1git (build 11939) (Nextcloud, osx-21.6.0 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"25.0.0.18","data":{"app":"PHP"}}

{"reqId":"XqfoG2Pu0YwvJivHiSyr","level":3,"time":"2022-10-20T10:32:47+00:00","remoteAddr":"myIPAddr","user":"myUser","app":"PHP","method":"PROPFIND","url":"/remote.php/dav/files/myUser/","message":"Nesting level too deep - recursive dependency? at /var/www/html/lib/private/Log/ExceptionSerializer.php#215","userAgent":"Mozilla/5.0 (Macintosh) mirall/3.6.1git (build 11939) (Nextcloud, osx-21.6.0 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"25.0.0.18","data":{"app":"PHP"}}

{"reqId":"4BsP1LSGPpLtRM3GyI34","level":3,"time":"2022-10-20T10:36:55+00:00","remoteAddr":"myIPAddr","user":"myUser","app":"PHP","method":"PROPFIND","url":"/remote.php/dav/files/myUser/","message":"Nesting level too deep - recursive dependency? at /var/www/html/lib/private/Log/ExceptionSerializer.php#215","userAgent":"Mozilla/5.0 (Macintosh) mirall/3.6.1git (build 11939) (Nextcloud, osx-21.6.0 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"25.0.0.18","data":{"app":"PHP"}}

{"reqId":"QIH8aM8OkRAdtKUVXTiH","level":3,"time":"2022-10-20T10:42:06+00:00","remoteAddr":"myIPAddr","user":"myUser","app":"PHP","method":"PROPFIND","url":"/remote.php/dav/files/myUser/","message":"Nesting level too deep - recursive dependency? at /var/www/html/lib/private/Log/ExceptionSerializer.php#215","userAgent":"Mozilla/5.0 (Macintosh) mirall/3.6.1git (build 11939) (Nextcloud, osx-21.6.0 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"25.0.0.18","data":{"app":"PHP"}}

{"reqId":"tebE6JDGHQ0PaGLE8LCL","level":3,"time":"2022-10-20T10:48:17+00:00","remoteAddr":"myIPAddr","user":"myUser","app":"PHP","method":"PROPFIND","url":"/remote.php/dav/files/myUser/","message":"Nesting level too deep - recursive dependency? at /var/www/html/lib/private/Log/ExceptionSerializer.php#215","userAgent":"Mozilla/5.0 (Macintosh) mirall/3.6.1git (build 11939) (Nextcloud, osx-21.6.0 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"25.0.0.18","data":{"app":"PHP"}}

{"reqId":"CcjDTTHfdsZrRugBZBHV","level":3,"time":"2022-10-20T10:55:31+00:00","remoteAddr":"myIPAddr","user":"myUser","app":"PHP","method":"PROPFIND","url":"/remote.php/dav/files/myUser/","message":"Nesting level too deep - recursive dependency? at /var/www/html/lib/private/Log/ExceptionSerializer.php#215","userAgent":"Mozilla/5.0 (Macintosh) mirall/3.6.1git (build 11939) (Nextcloud, osx-21.6.0 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"25.0.0.18","data":{"app":"PHP"}}

{"reqId":"Whf4lELHVcSxXxTXX5T0","level":3,"time":"2022-10-20T11:03:47+00:00","remoteAddr":"myIPAddr","user":"myUser","app":"PHP","method":"PROPFIND","url":"/remote.php/dav/files/myUser/","message":"Nesting level too deep - recursive dependency? at /var/www/html/lib/private/Log/ExceptionSerializer.php#215","userAgent":"Mozilla/5.0 (Macintosh) mirall/3.6.1git (build 11939) (Nextcloud, osx-21.6.0 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"25.0.0.18","data":{"app":"PHP"}}

{"reqId":"AClBtqYrpXjcD2jHsApi","level":3,"time":"2022-10-20T11:13:06+00:00","remoteAddr":"myIPAddr","user":"myUser","app":"PHP","method":"PROPFIND","url":"/remote.php/dav/files/myUser/","message":"Nesting level too deep - recursive dependency? at /var/www/html/lib/private/Log/ExceptionSerializer.php#215","userAgent":"Mozilla/5.0 (Macintosh) mirall/3.6.1git (build 11939) (Nextcloud, osx-21.6.0 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"25.0.0.18","data":{"app":"PHP"}}

Same time frame, this time from NGINX's perspective:

myIpAddr - myUser [20/Oct/2022:06:27:37 -0400] "PROPFIND /remote.php/dav/files/myUser/ HTTP/2.0" 500 0 "-" "Mozilla/5.0 (Macintosh) mirall/3.6.1git (build 11939) (Nextcloud, osx-21.6.0 ClientArchitecture: x86_64 OsArchitecture: x86_64)"

myIpAddr - myUser [20/Oct/2022:06:27:37 -0400] "PROPFIND /remote.php/dav/files/myUser/ HTTP/2.0" 500 0 "-" "Mozilla/5.0 (Macintosh) mirall/3.6.1git (build 11939) (Nextcloud, osx-21.6.0 ClientArchitecture: x86_64 OsArchitecture: x86_64)"

myIpAddr - myUser [20/Oct/2022:06:29:41 -0400] "PROPFIND /remote.php/dav/files/myUser/ HTTP/2.0" 500 0 "-" "Mozilla/5.0 (Macintosh) mirall/3.6.1git (build 11939) (Nextcloud, osx-21.6.0 ClientArchitecture: x86_64 OsArchitecture: x86_64)"

myIpAddr - myUser [20/Oct/2022:06:32:47 -0400] "PROPFIND /remote.php/dav/files/myUser/ HTTP/2.0" 500 0 "-" "Mozilla/5.0 (Macintosh) mirall/3.6.1git (build 11939) (Nextcloud, osx-21.6.0 ClientArchitecture: x86_64 OsArchitecture: x86_64)"

myIpAddr - myUser [20/Oct/2022:06:36:55 -0400] "PROPFIND /remote.php/dav/files/myUser/ HTTP/2.0" 500 0 "-" "Mozilla/5.0 (Macintosh) mirall/3.6.1git (build 11939) (Nextcloud, osx-21.6.0 ClientArchitecture: x86_64 OsArchitecture: x86_64)"

myIpAddr - myUser [20/Oct/2022:06:42:06 -0400] "PROPFIND /remote.php/dav/files/myUser/ HTTP/2.0" 500 0 "-" "Mozilla/5.0 (Macintosh) mirall/3.6.1git (build 11939) (Nextcloud, osx-21.6.0 ClientArchitecture: x86_64 OsArchitecture: x86_64)"

myIpAddr - myUser [20/Oct/2022:06:48:17 -0400] "PROPFIND /remote.php/dav/files/myUser/ HTTP/2.0" 500 0 "-" "Mozilla/5.0 (Macintosh) mirall/3.6.1git (build 11939) (Nextcloud, osx-21.6.0 ClientArchitecture: x86_64 OsArchitecture: x86_64)"

myIpAddr - myUser [20/Oct/2022:06:55:31 -0400] "PROPFIND /remote.php/dav/files/myUser/ HTTP/2.0" 500 0 "-" "Mozilla/5.0 (Macintosh) mirall/3.6.1git (build 11939) (Nextcloud, osx-21.6.0 ClientArchitecture: x86_64 OsArchitecture: x86_64)"

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):

• ./occ config:app:set circles route_to_circle --value ''

then try to enable the Circles app again ?

• ./occ app:enable circles

@ArtificialOwl could you have a look at #32432 (comment)? Maybe we can break the recursive structure. Otherwise I suggest dropping the $wrapper object from being logged.

I think this will be the next step.
Also check for other place that are loggin an object on exception

@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

1. Disable the circles app OR
2. Run php occ config:app:set circles route_to_circle --value 'files.view.index' (to be run as www-data) OR
3. Install and enable contacts app

Sideeffects for the workarounds

1. Circles won't be there (obviously)
2. Generated circle links point to the Nextcloud index page (instead of jumping to the contacts page)
3. none

Some technical background

The trace, like I observed it, is the following:

1. OCA\Circles\Model\Circle->jsonSerialize() is called, which invokes OCA\Circles\Model\Circle->getUrl()
2. OC\Route\Router->generate() is called with the circles app config value of route_to_circle. If that value is empty, the default constant contacts.contacts.directcircle is used for the $name parameter of OC\Route\Router->generate()
3. If the contacts app is not installed on the system, the route contacts.contacts.directcircle cannot be resolved, which throws a RouteNotFoundException. Router will try to log this exception here
4. Logging of the exception invokes the OC\Log\ExceptionSerializer, which tries to remove sensitive values from the log message before logging
5. The native recursion exception occures here because $values contains one or more objects (like OC\User\User) which contain recursive references and cannot be used for the in_array-check (btw.: I tried to rewrite it to foreach but that also failed)

What needs to be fixed/implemented (IMO)

In the circles app: only link to the contacts app if the contacts app is installed on the system. Otherwise use some system independent default route for https://github.com/nextcloud/circles/blob/3beecabfee1cfa6a532bea0e011a88e203f9d7d7/lib/Service/ConfigService.php#L179

In NC core: check if there is a way to circumvent that (recursive) objects are passed inside the array of $values in removeValuesFromArgs. (The only way I managed this currently is to filter objects in general and only allow simple types like strings etc. but that might not be desireable)

Worarounds that work for me

[...]
3. Install and enable contacts app

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.

@ArtificialOwl this does not work for me. I think it's because the value is checked for empty here: route_to_circle .

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

Yes, you are right; but how was it working before ?...

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 $values are structured, when giving them to the in_array-check. That would be something for NC core but like I said it's quite hard to reproduce.

Generally speaking: when fixing the log problem inside the circles-app, it would work for this particular problem discussed here. But nevertheless in general it could somehow happen, that the removeValuesFromArgs function is fed with "recursive objects", which IMO should be avoided because it can paralyze the whole NC system.

Yes, you are right; but how was it working before ?...
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.

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.

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.

+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
,"remoteAddr":"######","user":"######","app":"PHP","method":"POST","url":"/login","message":"Nesting level too deep - recursive dependency? at /var/www/html/lib/private/Log/ExceptionSerializer.php#215"
and is how I found this thread and the solution to try to disable circles

It might also be related to #23429 (comment)

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 ExceptionSerializer::removeValuesFromArgs() not handling variable references properly. If you want to recursively iterate arbitrary input, you must account for references (i.e. arrays referencing itself, e.g. $a = ["foo"]; $a[] = &$a;). This causes an infinite loop until either the memory limit or XDebug's recursion limit is reached.

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: ExceptionSerializer already limits recursion. But for some reason someone chose to filter sensitive information separately prior to the recursion depth checks in ExceptionSerializer::encodeArg(). Doesn't make much sense and causes these issues.

Calling ExceptionSerializer::removeValuesFromArgs() should be moved to ExceptionSerializer::encodeArg(). Then the issue will disappear.

I was just thinking about an quick fix, but honestly, ExceptionSerializer is a mess. It iterates the stack trace and all arguments multiple times and following what the code does is very hard. The methods seem to be in random order. Why? This class should be rewritten from scratch. Unfortunately I don't have enough time for this...

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

wget -q -O- https://github.com/nextcloud/server/commit/330523b7995db8702c7fb980c393d171d947ff94.patch | patch -p1

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 👍

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 25.0.4 and 24.0.10 🚀

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 :

1. remove group or user from Two Authentification enforced
2. log with your user credential back to nextcloud
3. enable TOTP in user settings
4. go back to admin setting page and enforce your 2auth back.

Hope this help !

I just had the same error.
I couldn't log-in. Manually deleting Circle App files in the container volume did the trick.

I can confirm everything from @TheIceMagmaCube. Same is true for me.

Manually deleting Circle App files in the container volume did the trick.

Couldn't you just disable the Circles app?

Manually deleting Circle App files in the container volume did the trick.

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 25.0.4. This should also fix the problem. If not, please report again 👍