Open j-schumann opened 2 weeks ago
In 3.4: Using rfc_7807_compliant_errors: true
(extra_properties => default) you keep the prefix right? In 4.x this breaks and you don't have these prefixes anymore on errors. We had so much going on that it was hard to think about everything and 4.0.3 has a bug fix as in 4.x these prefixes should've been removed. Indeed, hydra_prefix
has no incidence on errors, I'll try to find a way to add this behavior it may mitigate the BC break.
I hope my patch fixes your issue, I'll release by Friday
I just tested the 4.0.4 release and for me this issue seems to be fixed and in error responses the title and description with hydra prefix are back when using hydra_prefix: true
:+1:
Thanks :)
For me it is working only partially:
The prefix is restored (with hydra_prefix: true
) only for hydra:description, hydra:title. But not for the @type
.
Tests fail with:
--- Expected
+++ Actual
@@ @@
- '@type' => 'hydra:Error',
+ '@type' => 'Error',
API Platform version(s) affected: 4.0.3, 3.4.2
Description
In 4.0.3 + 3.4.2 the "hydra:" prefix was removed from error responses (in https://github.com/api-platform/core/pull/6624/commits/7d23c76fd13e2283af95e9aefc5540a1bc86215a). This breaks error handling in our clients in multiple APIP projects as they read
hydra:description
How to reproduce
APIP works in 4.0.2 -> update api-platform/state|validator to 4.0.3 without any other change -> hydra properties disappear
Possible Solution
a) Revert this "fix", it is a BC break which should not occur in a patch/minor version, especially not without previous deprecation or changelog note (in 4.0.3) b) Add an option to keep the prefix, as I would expect
serializer: hydra_prefix: true
to behave. This option should be enabled by default (else BC break)Additional Context
I don't know why this breaking change was introduced in 3.4.2, it was known to be breaking as it was noted in the Changelog:
This note should also have been on the 4.0.3 changelog as this was the first 4.x version that introduced that break. (At least it would have saved me half an hour debugging as nothing in the changelog indicated that the reason could be this version.)
I am not the only one relying on those response fields: https://github.com/api-platform/core/issues/5963#issuecomment-1808497808