Skip to content

Openapi request conformance - #5463

Draft
sethboyles wants to merge 2 commits into
mainfrom
openapi-request-conformance
Draft

sethboyles wants to merge 2 commits into
mainfrom
openapi-request-conformance

Conversation

@sethboyles

Copy link
Copy Markdown
Member

Thanks for contributing to cloud_controller_ng. To speed up the process of reviewing your pull request please provide us with:

  • A short explanation of the proposed change:

  • An explanation of the use cases your change solves

  • Links to any other associated PRs

  • I have reviewed the contributing guide

  • I have viewed, signed, and submitted the Contributor License Agreement

  • I have made this pull request to the main branch

  • I have run all the unit tests using bundle exec rake

  • I have run CF Acceptance Tests

sethboyles and others added 2 commits September 16, 2026 14:40
The request specs already drive the real rack app through rack-test, so
every example is a request/response pair the description in docs/openapi
either covers or doesn't. openapi_first wraps that app and records the
verdict, which gives per-PR contract checking with no deployed CF, no
proxy and no traffic capture -- and tells us which described routes
nothing exercises, which recorded traffic never can.

Off unless OPENAPI_CONFORMANCE is set, so a normal run is untouched: the
gem isn't required and the app isn't wrapped.

A first pass over spec/request reaches 248 of the 253 described routes
and records 31 violations. Some are description defects -- relationships
that come back null where the description says object, guid fields that
aren't marked nullable, a `since` that isn't a double -- and some are
request specs using synthetic guids like 'app1_guid' where the
description says format: uuid. Telling those apart is the next step, so
the GitHub Action reports rather than gates.

ai-assisted=yes

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Of the 31 violations the first pass reported, 17 or so were `format: uuid`
failures from the roughly 250 places in spec/request that hand a model a
literal guid like 'app1_guid'. Specs assert on those literals, so they
can't just be swapped for real UUIDs -- and real Cloud Controller guids
are SecureRandom.uuid, so the check only has signal against recorded
traffic. Count them, don't list them.

The suppression is deliberately narrow: a compound error keeps its row,
so "... format: uuid. value at `/relationships/space/data` is not an
object" still shows up. That leaves about 14 rows that are worth reading
-- relationships that come back null where the description says object,
guid fields that aren't marked nullable, a `since` that isn't a double.

Which of the two buckets a row lands in isn't stable between runs, since
it depends on which request happened to be validated last, so the
headline number stays the total and the split is shown beneath it.

Also drops "(spike)" from the workflow name now that it does something
useful. It stays informational: the description disagrees with the API
in a handful of places, so there is nothing honest to gate on yet.

ai-assisted=yes

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@sethboyles
sethboyles marked this pull request as draft September 17, 2026 16:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant