SoapClient::__doRequest undocumented backwards incompatible in PHP 8.5

[brainfoolong]

Description

I found an undocumented backwards incompatible change that is breaking existing SoapClient implementations?!

Here, this break is not listed
https://github.com/php/php-src/blob/php-8.5.0RC3/UPGRADING

Here, this change is documented but not as breaking

php-src/NEWS

Line 341 in ad19b3e

- SOAP:

The signature of SoapClient::__doRequest has changed, so it triggers the following errors in userland code

Declaration of xxxt::__doRequest($request, $location, $action, $version, $oneWay = 0): ?string must be compatible with SoapClient::__doRequest(string $request, string $location, string $action, int $version, bool $oneWay = false, ?string $uriParserClass = null): ?string

Which i guess is quite common because you almost always have to override this function in SoapClient.

Also with the now per default enabled opcache for all in PHP 8.5 and the default opcache settings, you may not notice this errors because opcache swallows this error per default after the file is cached. This really hunted me because i've tested previous 8.5 versions without this error, until recently i found out about the opcache bug hidding thing.

Do i miss something?

PHP Version

PHP 8.5RC3, since PHP 8.5beta1

Operating System

No response

[kocsismate]

@brainfoolong Thanks for the report, and sorry for the trouble! I've just fixed the missing UPGRADING note in #20278.

As for opcache: isn't a version change supposed to invalidate the cache? 🤔

[brainfoolong]

As for opcache: isn't a version change supposed to invalidate the cache?

Thx for the update.

Yes, it does. It also invalidate when you change the file. But when you do upgrading from php 8.4 to 8.5 it's common to hit more errors than just this in a test suite of a few hundred tests.

And if you try to reproduce errors with a second run, they disappear "magically". Because of the opcache and default opcache.record_warnings=0 option in php.ini that you are probably unaware of when you never have used opcache before.

So, in our case, we didn't know this option just was unable to reproduce this error the second time we ran the tests. This also happened with a lot of other errors as well.

This workflow and knowledge problem was on our side and it's not related to this exact error, but yeah, the opcache default for people never enabled opcache before will be a pain for many people to debug, i guess.

Edit: We now enabled opcache.record_warnings=1 to always see all errors, no matter if they are cached or not (Default behaviour as with no opcache enabled)