Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specmatic Stub does not generate correct response for single JSON string #1087

Open
noelmccrory opened this issue May 2, 2024 · 3 comments
Assignees
Labels
bug Something isn't working

Comments

@noelmccrory
Copy link

noelmccrory commented May 2, 2024

Description
I have a Spring Boot API which uses an enum as the ResponseEntity type:

public ResponseEntity<DocumentStatus> getDocumentStatus(@PathVariable UUID id)

When I call my API it produces the following response:

content-type: application/json
body: "COMPLETE"

(Note: the double quotes which make this valid json)

The OpenAPI Spec (which was autogenerated from springdoc) has:

        '200':
          description: OK
          content:
            'application/json':
              schema:
                type: string
                enum:
                  - IN_PROGRESS
                  - COMPLETE
                  - FAILED
              examples:
                GET_DOCUMENT_STATUS:
                  value: COMPLETE

When I run the Specmatic Stub and call this endpoint, it returns the following:

    200 OK
    X-Specmatic-Result: success
    Content-Type: text/plain
    
    COMPLETE

Note: The double quotes are missing and the Content Type is wrong. This then results in an error on the consumer tests:

Could not extract response: no suitable HttpMessageConverter found for response type [class com.xxxx.model.DocumentStatus] and content type [text/plain]

Even if I update an API Spec to force the double quotes, it still results in Content-Type: text/plain:

        '200':
          description: OK
          content:
            'application/json':
              schema:
                type: string
                enum:
                  - '"IN_PROGRESS"'
                  - '"COMPLETE"'
                  - '"FAILED"'
              examples:
                GET_DOCUMENT_STATUS:
                  value: '"COMPLETE"'

Steps to reproduce
See above.

Expected behavior
Content-Type should be application/json and the string in the response body should be wrapped in double quotes.

Screenshots
N/A

System Information:

  • OS & version: MacOS 14.4.1
  • Specmatic version: 1.3.13
  • JDK version: 21

Additional context
It looks like a similar issue was present on the request generation - #898

It seems similar to this issue - mock-server/mockserver#1101

This is valid JSON according to https://jsonlint.com/
image

@noelmccrory
Copy link
Author

I was able to workaround this by using a stub expectation file, rather than an example in the API Spec.

{
  "http-request": {
    "path": "/document/(docid:uuid)/document-status",
    "method": "GET"
  },
  "http-response": {
    "status": 200,
    "body": "COMPLETE",
    "headers": {
      "Content-Type": "application/json"
    }
  }
}

@noelmccrory
Copy link
Author

It looks like there are similar issues for Contract Tests. I get the following error:

  Request to http://localhost:60199 at 2024-5-2 3:13:13.389
    GET /document/e49c9039-5c89-4396-9dff-f3b9a32cacc9/document-status
    Authorization: Bearer abcdef
    Accept-Charset: UTF-8
    Accept: */*
    Content-Type: NOT SENT
    
    

  Response at 2024-5-2 3:13:13.389
    200 OK
    Content-Type: application/json
    
    "COMPLETE"

 Scenario: GET /document/(id:uuid)/document-status -> 200 | EX:GET_DOCUMENT_STATUS has FAILED
Reason: Testing scenario "GET /document/(id:uuid)/document-status. Response: OK"
	API: GET /document/(id:uuid)/document-status -> 200
	
	  >> RESPONSE.BODY
	  
	     Contract expected ("IN_PROGRESS" or "COMPLETE" or "FAILED") but response contained "\"COMPLETE\""

Interestingly, this is returning an application/json response, but seems like another part of Specmatic is expecting it to be just plaintext.

@yogeshnikam671
Copy link
Member

Hey @noelmccrory, thanks for reporting this. Really appreciate the detailed logs that you have shared!
We will try to reproduce the issue and share the root cause with you in a while.
We will then plan to fix it as per the root cause analysis.

@harikrishnan83 harikrishnan83 added the bug Something isn't working label May 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants