GuzzleHttp shipped with app conflicts with system GuzzleHttp on NC 27

[origintopleft]

When syncing to NextCloud 27.0.0, most files sync fine, but some files fail, with the client reporting HTTP 500 errors. This is printed in the logs when those files fail (I watched the logs and initiated a sync to see what the error is)

PHP Fatal error: Declaration of Aws\S3\ObjectCopier::promise() must be compatible with GuzzleHttp\Promise\PromisorInterface::promise(): GuzzleHttp\Promise\PromiseInterface in /var/www/html/3rdparty/aws/aws-sdk-php/src/S3/ObjectCopier.php on line 82

Originally, I thought it was a bug in server itself, but after discussion and some help at nextcloud/server#39407 , it got tracked down to this app shipping its own Guzzle, presumably on accident.

In my case a full uninstall of the app fixed things (I don't even have ES installed locally, I think I installed it by accident), but it may also be possible to simply remove the offending PromisorInterface.php

[sgl-mnrch]

I can confirm that behaviour. Installing and configuring the ES full text search leads to this error. I have a local ES cluster running.

  Error    PHP                Declaration of     
                              Aws\S3\ObjectCopier::promise()                           
                              must be compatible                               
                              with                                             
                              GuzzleHttp\Promise\PromisorInterface::promise():                           
                              GuzzleHttp\Promise\PromiseInterface                           
                              at                                               
                              /var/www/html/3rdparty/aws/aws-sdk-php/src/S3/ObjectCopier.php#82      

[abysso2]

Same here and this is a real issue for me: My organisation needs fulltextsearch to manage the content and we need S3 to provide an archive for cold data.

Is this issue aware to the devs?

[developmentforpeople]

Thanks @origintopleft and @sgl-mnrch for guiding me to resolve temporarily this issue in my Nextcloud instance using S3 for external storage!! :) Here you can find my humble solution :)

# Resolve temporarely just creating a symlink to main library and ignoring the one shipped within "fulltextsearch_elasticsearch" app:
mv /var/www/html/custom_apps/fulltextsearch_elasticsearch/vendor/guzzlehttp /var/www/html/custom_apps/fulltextsearch_elasticsearch/vendor/guzzlehttp_DFP
ln -s /var/www/html/3rdparty/guzzlehttp /var/www/html/custom_apps/fulltextsearch_elasticsearch/vendor/guzzlehttp

@abysso2 maybe you are interested too ;)

[abysso2]

Ah come on ... of course i am interested :-D Thank you for this workaround, works like a charm here ...

[dee-kryvenko]

I am not sure this workaround is applicable in AIO environment, probably going to be reverted automatically - docker containers are immutable, not to mention potential issues during following upgrades.

[abysso2]

/var/www/html/custom_apps/fulltextsearch_elasticsearch/vendor/guzzlehttp seems not to exist in fulltestsearch_elasticsearch 27.0.5, but the issue does not seem to be resolved ... can anybody confirm this?

[abysso2]

Bump

[dee-kryvenko]

It works for me, I guess you want to check on the manual workarounds you applied previously...

[joshtrichards]

Fixed in #330