Cloud-Firestore throws Maximum Call Stack Size errors on numerous Firestore statements when using GRPC (PHP pecl) library 1.69.0.

[BobDankert]

Cloud-Firestore throws Maximum Call Stack Size errors on numerous Firestore statements when using GRPC (PHP pecl) library 1.69.0. This does not consistently happen in the same spot but we have a call that makes a few dozen Firestore calls, and it always fails with this error in one of the calls (which call is inconsistent though).

Reverting back to GRPC 1.67.0 from GRPC 1.69.0 fixes the issue. I don't know if this is an issue with the PHP PECL library GRPC or with this library, but given this library requires GRPC, I am starting by submitting this issue here.

Environment details

• OS: Docker / Apache on Linux
• PHP version: 8.3.7
• Package name and version: google/cloud-firestore version 1.47.3

Steps to reproduce

1. Execute Numerous Firestore calls while running GRPC 1.69.0

ERROR CALL STACK:

Error: Maximum call stack size of 8339456 bytes (zend.max_allowed_stack_size - zend.reserved_stack_size) reached. Infinite recursion? in file /var/www/website/backend/vendor/google/gax/src/CredentialsWrapper.php on line 244
Stack trace:
  1. Error->() /var/www/website/backend/vendor/google/gax/src/CredentialsWrapper.php:244
  2. Google\ApiCore\CredentialsWrapper->Google\ApiCore\{closure}() [internal]:0
  3. Grpc\Call->startBatch() /var/www/website/backend/vendor/grpc/grpc/src/lib/ServerStreamingCall.php:43
  4. Grpc\ServerStreamingCall->start() /var/www/website/backend/vendor/grpc/grpc/src/lib/BaseStub.php:368
  5. Grpc\BaseStub->Grpc\{closure}() /var/www/website/backend/vendor/grpc/grpc/src/lib/BaseStub.php:593
  6. Grpc\BaseStub->_serverStreamRequest() /var/www/website/backend/vendor/google/gax/src/Transport/GrpcTransport.php:227
  7. Google\ApiCore\Transport\GrpcTransport->startServerStreamingCall() /var/www/website/backend/vendor/google/gax/src/GapicClientTrait.php:664
  8. Google\Cloud\Firestore\V1\Gapic\FirestoreGapicClient->Google\ApiCore\{closure}() /var/www/website/backend/vendor/google/gax/src/Middleware/CredentialsWrapperMiddleware.php:60
  9. Google\ApiCore\Middleware\CredentialsWrapperMiddleware->__invoke() /var/www/website/backend/vendor/google/gax/src/Middleware/FixedHeaderMiddleware.php:67
 10. Google\ApiCore\Middleware\FixedHeaderMiddleware->__invoke() /var/www/website/backend/vendor/google/gax/src/Middleware/RetryMiddleware.php:94
 11. Google\ApiCore\Middleware\RetryMiddleware->__invoke() /var/www/website/backend/vendor/google/gax/src/Middleware/RequestAutoPopulationMiddleware.php:73
 12. Google\ApiCore\Middleware\RequestAutoPopulationMiddleware->__invoke() /var/www/website/backend/vendor/google/gax/src/Middleware/OptionsFilterMiddleware.php:60
 13. Google\ApiCore\Middleware\OptionsFilterMiddleware->__invoke() /var/www/website/backend/vendor/google/gax/src/GapicClientTrait.php:630
 14. Google\Cloud\Firestore\V1\Gapic\FirestoreGapicClient->startCall() /var/www/website/backend/vendor/google/cloud-firestore/src/V1/Gapic/FirestoreGapicClient.php:1243
 15. Google\Cloud\Firestore\V1\Gapic\FirestoreGapicClient->runQuery() /var/www/website/backend/vendor/google/cloud-core/src/ExponentialBackoff.php:97
 16. call_user_func_array() /var/www/website/backend/vendor/google/cloud-core/src/ExponentialBackoff.php:97
 17. Google\Cloud\Core\ExponentialBackoff->execute() /var/www/website/backend/vendor/google/cloud-core/src/GrpcRequestWrapper.php:134
 18. Google\Cloud\Core\GrpcRequestWrapper->send() /var/www/website/backend/vendor/google/cloud-core/src/GrpcTrait.php:79
 19. Google\Cloud\Firestore\Connection\Grpc->send() /var/www/website/backend/vendor/google/cloud-firestore/src/Connection/Grpc.php:267
 20. Google\Cloud\Firestore\Connection\Grpc->runQuery() /var/www/website/backend/vendor/google/cloud-firestore/src/Query.php:322
 21. Google\Cloud\Firestore\Query->Google\Cloud\Firestore\{closure}() /var/www/website/backend/vendor/google/cloud-core/src/ExponentialBackoff.php:97
 22. call_user_func_array() /var/www/website/backend/vendor/google/cloud-core/src/ExponentialBackoff.php:97
 23. Google\Cloud\Core\ExponentialBackoff->execute() /var/www/website/backend/vendor/google/cloud-firestore/src/Query.php:320
 24. Google\Cloud\Firestore\Query->documents() /var/www/website/..... ORIGINATING CODE

The originating code in question works great with GRPC 1.67.0 but errors in GRPC 1.69.0. Here is the code (cleaned up for clarity):

$firestoreClient = FirestoreDatabase::getInstance()->getFirestoreClient();
$firestoreCollectionDriverSchedule = $firestoreClient->collection(Config::$config['Firebase']['firestoreCollectionId']);
$firestoreSchedules = $firestoreCollectionDriverSchedule->where('date', '=', $date)->where('state', '=', $state);
$documents = $firestoreSchedules->documents();

It errored on the last line of code. As stated, I can run this same request and it will sometimes error on a different firestore statement, but it seems like ALL firestore statements are having this issue, though it may not be the first one.

Note I have not tried anything other than GRPC 1.67.0 (which works) and GRPC 1.69.0 (which does not work). It's quite possible that 1.68.0 would work - I have not tried it.

[haizadvnet]

Hi, I'm using GRPC 1.66.0 in two environments, both running PHP 8.3. One setup runs without issues, but the other intermittently hits the "Maximum call stack size" error. Given that PHP 8.3 now includes a new INI directive—zend.max_allowed_stack_size—to control the native stack size, I suspect these changes in memory limits might be affecting the results. For more details, see https://www.php.net/manual/en/migration83.other-changes.php#migration83.other-changes.ini

@BobDankert did you happen to modify any memory settings besides reverting to GRPC 1.67?

[BobDankert]

@haizadvnet I didn't make any other changes other than the GRPC version, going from 1.69.0 to 1.67.0. This is using a docker php environment so I am certain that nothing else changed, as this was the only change to the docker file.

This is on PHP 8.3.7 (FROM php:8.3.7-apache-bookworm)

I've confirmed that the zend.max_allowed_stack_size is 0.

Every developer on our team was having this issue with the 1.69.0 build, and none of them have had this issue with the 1.67.0 build. I'm happy to look into additional details/things if it would help!

[ChrisGalliano]

We having the same problem, with the latest version of the google/cloud-firestore package and ext grpc 1.70.0

Also this comment right from the first file in stacktrace looks... related

vendor/google/gax/src/CredentialsWrapper.php:241

        // NOTE: changes to this function should be treated carefully and tested thoroughly. It will
        // be passed into the gRPC c extension, and changes have the potential to trigger very
        // difficult-to-diagnose segmentation faults.

[haizadvnet]

@haizadvnet I didn't make any other changes other than the GRPC version, going from 1.69.0 to 1.67.0. This is using a docker php environment so I am certain that nothing else changed, as this was the only change to the docker file.

This is on PHP 8.3.7 (FROM php:8.3.7-apache-bookworm)

I've confirmed that the zend.max_allowed_stack_size is 0.

Every developer on our team was having this issue with the 1.69.0 build, and none of them have had this issue with the 1.67.0 build. I'm happy to look into additional details/things if it would help!

@BobDankert I haven’t tried GRPC 1.69.0 yet, but since 1.67.0 works fine for you, there might be something worth investigating in that particular version. 🤔 Could it be related to your Docker environment setup?

Worth to mention now that I’m currently using 1.70.0, and every call returns Maximum Call Stack Size with no successful responses at all.

My php version is 8.3.10.

Anyway, this issue seems related. Some suggest disabling stack size checks in the php.ini as a workaround: https://github.com/googleapis/gax-php/issues/584#issuecomment-2342772917

[haizadvnet]

It seems the issue is actually in gax-php. I've added a comment on googleapis/gax-php#584 explaining my experience and the change that resolved the Maximum call stack size exceeded error.

[bshaffer]

@haizadvnet I've posted the issue to the grpc repo here: https://github.com/grpc/grpc/issues/39509

I will try to take a closer look. In the meantime, has anyone tried this with the latest gRPC version (at this time, 1.72)?

[pifagor87]

yes, the problem still exists in gRPC version 1.72