Openapi.yml uses patternProperties which is not supported by our dependencies

I pushed up a rough start to test.

Putting this down to work on other issues for now

Merged 0.x and pushed some fixes, but there are multiple deprecations that I don't understand yet and a test fail that I am not sure what to do with.

Saving attribution.

Just merged 📌 Remove dead `ApiResponseValidator::performXbValidation()` Active we may have to add this back here if we need it

The removal of x-xb-validation in /openapi.yml seems to have been accidental in this commit: https://git.drupalcode.org/project/experience_builder/-/merge_requests/1... ? 🤔

Following up on non-draft MRs that have been open for a long time. That led me here. What's next here? Is this still relevant?

We should remove patternProperties from openapi.yml if it doesn't work, but otherwise I am not sure we need to strictly validate here, Drupal will do it for us anyway?

This MR is quite old and out of sync with 0.x. Let's start with a rebase. 👆

re #12 yes, still relevant. I think any time we have `patternProperties` in openapi that part is not getting validated. example 🐛 XbConfigEntityHttpApiTest Active

Although I think my approach in https://git.drupalcode.org/project/experience_builder/-/merge_requests/226 probably could work, I think it is probably overly complicated for what it gets us.

I think addtionalProperties gets us everything except key checking. Although not ideal I don't think we have had actual problems with invalid keys and it seem like an edge case of what we are likely to hit

So added new MR that simply adds a test that make sure we don't add any new uses addtionalProperties, which I think has happened since we first opened this issues. We would have to make a few changes to get the new test to pass

Tests are failing I think because the validation is now starting be enforced for sections that were being skipped because of our use of patternProperties

tedbow → closed merge request !226

I think we should get this MR in ASAP. We have 3 response that are not being validated but appear to be. People would waste time in other issue updating the response spec thinking it is actually being enforced.

1 of the responses already fails the validation that is there and the other 2 could be broken at any point and no one would know. This is really just to stop the bleeding and 📌 Decide on an approach for writing tests for OpenAPI integration Active can figure the way forward

I created 📌 Enforce response keys in openapi if possible Active to figure out if we can actually validate keys.

Need to bring back more changes after merging with 0.x

another follow-up 🐛 Openapi.yml uses patternProperties which is not supported by our dependencies Needs work

Agree with the rationale, and the test is helpful until we get an upgrade to the OpenAPI spec validator - which is somewhat outside the scope of this project.

This adds onto 📌 Make all XB HTTP API routes consistently prefixed Active , in making XB's use of OpenAPI less brittle! 🚀

Landed 📌 OpenAPI spec insufficiently precise for `LayoutComponent` Active while waiting for this to be green.

🎉

Well done!

Automatically closed - issue fixed for 2 weeks with no activity.