Requests checking request method type of previous request

[nichwall]

(originally posted in Discord under the associated thread https://discord.com/channels/923258363540815912/1126857048273981551/1208217864054636626)

Originally reported with wiretap 0.1.1

Requests to an endpoint fails if the previous request was to an endpoint that does not have the same request type (GET, POST, etc). This behavior has been encountered using both Python and curl.

The error I'm getting is:

POST operation request content type 'POST' does not exist.
The path was found, but there was no 'POST' method found in the spec.
How to fix this violation:
Add the missing operation to the contract for the path

Current spec: https://github.com/nichwall/audiobookshelf/blob/collection_routes_openapi_v1/build-docs/swagger-output.json

Testing with the /login endpoint just using curl to POST works on a fresh run. However, after running the Python script the same curl POST to /login fails with a line number of 296 instead of 354 (so the violations references /api/items/{id} in the spec instead of /login).

More details

The Python script makes the following requests (all valid calls from before making the OpenAPI spec):

• POST to /login (succeeds)
• GET to /api/libraries (fails with missing GET to line 354, or /login in spec)
• GET to /api/libraries/{id}/items (succeeds)
• GET to /api/items/{id} (fails with invalid schema, unrelated to this error)

Sending the curl POST to /login then fails with a missing GET definition, referencing /api/items/{id} in spec.

After adding a dummy get request to the /login endpoint, the get request to /api/libraries immediately afterwards passes validation (but the POST to /login after the script will still fail).

Steps to reproduce

Spec without all request types defined on the previous endpoint hit through wiretap.

[nichwall]

This may be caused by splitting a path into two in the spec, as mentioned in https://github.com/daveshanley/vacuum/issues/473

That might also explain why it happens intermittently, but working correctly on the second request is strange.

[daveshanley]

I tried running this workflow, and recorded it. I was unable to re-produce these issues. The (/api/libraries/{id}/item) fails because it's a genuine 404, there is no endpoint in the spec that matches.

This is running the spec provided above, in mock mode (-x), Running postman against this workflow returns all the expected values and I cannot re-create the errors.

https://github.com/pb33f/wiretap/assets/187345/57bd6386-b50d-4ba5-a301-01098c3dac02