ci: use php 8.5
| Q | A |
|---|---|
| Branch | main |
| License | MIT |
This PR updates the GitHub Actions workflow to use the latest stable PHP version, 8.5, in the CI pipeline.
The error of the "PHPUnit + Behat (PHP 8.5) (MongoDB)" job is already present on the main branch.
The errors of others behat jobs appear to be related to the following deprecation https://wiki.php.net/rfc/warnings-php-8-5#coercing_nan_to_other_types
<response>
<title>An error occurred</title>
<detail>Warning: unexpected NAN value was coerced to string in
/code/vendor/doctrine/dbal/src/Driver/PDO/Statement.php line 26
</detail>
<status>500</status>
<type>/errors/500</type>
<trace>
<function>handleError</function>
<class>Behat\Testwork\Call\Handler\RuntimeCallHandler</class>
<type><![CDATA[->]]></type>
</trace>
<trace>
<file>/code/vendor/doctrine/dbal/src/Driver/PDO/Statement.php</file>
<line>26</line>
<function>bindValue</function>
<class>PDOStatement</class>
<type><![CDATA[->]]></type>
</trace>
When the value is NaN, INF, or -INF, PDO::bindValue with PDO::PARAM_STR appears to convert to a string and throw the warning Warning: unexpected NAN value was coerced to string
Note: These values are not compatible with SQLite, the value is 0, unlike postgres.
<?xml version="1.0"?><response><id>2</id><myFloatField>NAN</myFloatField></response>
<?xml version="1.0"?><response><id>3</id><myFloatField>INF</myFloatField></response>
`<?xml version="1.0"?>\n<response><id>4</id><myFloatField>-INF</myFloatField></response>
no idea how to fix it... Should the test be ignored in PHP 8.5?
This failure is probably related to the changes:
--- Failed steps:
001 Example: | NaN | # features/xml/deserialization.feature:74
Then the response status code should be 201 # features/xml/deserialization.feature:68
Current response status code is 500, but 201 expected. (Behat\Mink\Exception\ExpectationException)
839 scenarios (837 passed, 1 failed, 1 undefined)
5481 steps (5470 passed, 1 failed, 1 undefined, 9 skipped)
6m38.62s (324.02Mb)
Add a Then print last JSON response in there to know what's wrong. There are instructions in CONTRIBUTING.md if you need the commands to run the tests.
The error <response><title>An error occurred</title><detail>Warning: unexpected NAN value was coerced to string in /code/vendor/doctrine/dbal/src/Driver/PDO/Statement.php line 26</detail> was a dump of the response. I think it's the same thing as step `Then print last JSON response.
With PHP 8.5 and PDO, I have
docker run --rm php:8.5-cli php -r '
$pdo = new PDO("sqlite::memory:");
$stmt = $pdo->prepare("
WITH dummy(value) AS (VALUES ('1'), ('2'))
SELECT * FROM dummy WHERE value = :value
");
$stmt->bindValue(":value", NAN, PDO::PARAM_STR);
$stmt->execute();
var_dump($stmt->fetchAll());
'
Warning: unexpected NAN value was coerced to string in Command line code on line 7
array(0) {
}
I will investigate further
Interesting this means that the issue is inside Symfony transformation? I'm not even sure why we support XML to be honest xD
@soyuka There are Two problems:
- PDO casts NAN to string and with php8.5, there is a warning
unexpected NAN value was coerced to stringhttps://wiki.php.net/rfc/warnings-php-8-5#coercing_nan_to_other_types
I've reported the problem in the Doctrine and PHP repository, but it seems that this needs to be handled at the application level. See https://github.com/doctrine/dbal/pull/7249 and https://github.com/php/php-src/issues/20666
- The Symfony XML Encoder also emits a warning
<?xml version="1.0"?>\n
<response><title>An error occurred</title><detail>Warning: unexpected NAN value was coerced to string in /app/vendor/symfony/serializer/Encoder/XmlEncoder.php line 483</detail><status>500</status><type>/errors/500</type><trace><file>/app/vendor/symfony/serializer/Encoder/XmlEncoder.php</file><line>483</line><function>handleError</function><cl
I created a PR @see https://github.com/symfony/symfony/pull/62740
I have modified ResourceWithFloat entity and ResourceWithFloat document so that the CI was successful but that doesn't seem like the right solution to me...
I have modified ResourceWithFloat entity and ResourceWithFloat document so that the CI was successful but that doesn't seem like the right solution to me...
it looks like any user should do these checks so I don't think that there's a better fix then this..
many thanks for this @aaa2000 !