You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The failing tests from PR #132 were merged into master, so now all the checks are failing for new PRs:
There was 1 failure:
1) SchemaTest::testNullable
Failed asserting that false is null.
/home/runner/work/php-openapi/php-openapi/tests/spec/SchemaTest.php:66
The issue is caused by this ternary operator in src/spec/Schema.php, which will always evaluate to true (thereby always setting nullable to false, and never actually null):
This always evaluates to the true side of the operator because hasProperty() also returns true if an attribute is defined, whether or not it has a value:
I see two quick solutions to this problem, but I wanted to discuss them with you guys before I open a PR:
As far as I see, Schema::attributeDefaults() is the only place where the SpecBaseObject::hasProperty() method is called, so a simple fix (which passes all the tests) would be to simplify the method like this:
Is there a reason why hasProperty() also checks if an attribute is defined? The method kinda feels misnamed.
The ternary conditional in attributeDefaults() could be rewritten to use isset:
'nullable' => isset($this->type) ? false : null,
But isset of course calls __isset(), which itself calls attributeDefaults(), so this might cause a recursion error.
Thoughts?
The text was updated successfully, but these errors were encountered:
victorstanciu
changed the title
PR #132 broke the unit tests
Unit tests are broken in master
Dec 10, 2021
victorstanciu
changed the title
Unit tests are broken in master
Unit tests are broken in master since PR #132
Dec 10, 2021
cebe
added
bug
Something isn't working
under discussion
feature/enhancement needs more input to decide if or how it should be implemented.
labels
Dec 21, 2021
The failing tests from PR #132 were merged into master, so now all the checks are failing for new PRs:
The issue is caused by this ternary operator in
src/spec/Schema.php
, which will always evaluate totrue
(thereby always settingnullable
tofalse
, and never actuallynull
):php-openapi/src/spec/Schema.php
Line 130 in 336bd8d
This always evaluates to the
true
side of the operator becausehasProperty()
also returnstrue
if an attribute is defined, whether or not it has a value:php-openapi/src/SpecBaseObject.php
Lines 300 to 303 in 336bd8d
And of course,
type
is a defined attribute of theSchema
object:php-openapi/src/spec/Schema.php
Line 92 in 336bd8d
I see two quick solutions to this problem, but I wanted to discuss them with you guys before I open a PR:
As far as I see,
Schema::attributeDefaults()
is the only place where theSpecBaseObject::hasProperty()
method is called, so a simple fix (which passes all the tests) would be to simplify the method like this:Is there a reason why
hasProperty()
also checks if an attribute is defined? The method kinda feels misnamed.The ternary conditional in
attributeDefaults()
could be rewritten to useisset
:But
isset
of course calls__isset()
, which itself callsattributeDefaults()
, so this might cause a recursion error.Thoughts?
The text was updated successfully, but these errors were encountered: