fix(metadata): Use operation output DTO in ObjectMapperProcessor#7611
fix(metadata): Use operation output DTO in ObjectMapperProcessor#7611Spomky wants to merge 1 commit intoapi-platform:4.2from
Conversation
|
Thanks @Spomky for addressing this 🤟 Yes, this will cover the use case of having a custom output DTO for state processors, but I just realized it will only work if a custom input DTO is also defined; otherwise, it won't reach the final lines where the output is mapped. We may need to refactor the entire method to explicitly handle all possible combinations:
|
|
I'm afraid that touching |
|
Correct. |
11d74db to
a5cbb02
Compare
|
Modifications done. I see 4 cases: no mapping, input mapping, output mapping, and input/output mapping. I will add some tests to make sure it is fine. |
|
Tests are failing because it is really not that simple. |
1853722 to
0587ff6
Compare
…per Processor return
0587ff6 to
5b38dea
Compare
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This PR follows up on #7601 and applies the same fix to the
ObjectMapperProcessor.While #7601 addressed the provider side by properly using the operation output class when defined, the processor was still relying on
$operation->getClass(). This change updates the processor to use the operation’s output DTO ($operation->getOutput()['class'] ?? $operation->getClass()), ensuring consistent behavior between providers and processors.ping @yceruto