Open API Generating Collection does not properly generate string request body when using format

[mtaylorfsmb]

Describe the bug
I have an OpenAPI YAML file that I in Postman that I'm using to generate a collection. Whenever it generates the collection it generates request bodies that have bad values for properties that are string but have a format string. Specifically it always puts in "" or "", etc. But this isn't valid for a formatted string so running the validation option under Test produces an error for each one.

To Reproduce
Steps to reproduce the behavior:

Sample YAML file.

# Need to pass user info to requests so we can properly set audit - security?
openapi: "3.0.0"
info:
  title: Demo
  version: "0.1.8"
paths:
  /blah:
     post:
        requestBody:
           content:
              application/json:
                 schema:
                      $ref: '#/components/schemas/MyData"
components:
   schemas:
      MyData:
      properties:
         aDate: 
            type: string
            format: date
         anEnum:
             type: string
             enum: [ 'A', 'B', 'C' ]
         aNumber:
             type: integer
         notNeeded:
             type: string
             nullable: true

What gets generated for the body is something like this:

{
    "aDate": "<date>",
    "anEnum": "<string>",
    "aNumber": "<number>",
    "notNeeded": "<string>"
}

Expected behavior

When a property is nullable then ideally it should be set to null (at least for strings and objects) so the collection doesn't generate a potentially bad value.

For enums then ideally it should put in a placeholder with possible values or just leave blank.

For dates or other formatted strings ideally it'll generate a formatted example value or leave blank.

For numbers it should put a numeric 0 in or leave blank.

As it stands now, after auto-generating the collection I would then have to manually clean it all up before I could give it to someone to use as an example. Furthermore using the Validation button on the Test tab flags each of these properties as badly formatted.

Screenshots
If applicable, add screenshots to help explain your problem. Please make sure the screenshot does not contain any sensitive information such as API keys or access tokens.

App information (please complete the following information):

• App Type Native App
• Postman Version 7.33.0
• OS: Windows 10 x64

Additional context
Add any other context about the problem here.

[VShingala]

@mtaylorfsmb You can provide options while generating collection under Show advanced setting dropdown, here you can set Request parameter generation and Response parameter generation options to use Example instead of Schema.

What this will do is use Eample/Fake value according to your schema and generate an actual value which can be validated correctly further.

Try it out, and let me know any issue you might have.

[mtaylorfsmb]

@VShingala Going that way helps some. Firstly, if the other approach doesn't really work at all except for perhaps basic strings then why even give it as an option?

The problems with using the examples is that it impacts all values. So every schema needs an example. But also the parameters in paths, which use variables when you use the other approach, now just use an example value. In my experience parameters in paths use variables and request/response bodies use examples. So either approach requires manually modifying the generated collection.

[mtaylorfsmb]

@VShingala sorry I was incorrect about path parameters using vars. It doesn't do that, I was just used to doing that. However I tried putting an example on the parameter and it was ignored when it was generated.

 parameters:
      - in: path
        name: value
        required: true
        type: string
        example: "{{value}}"

It generated a random string value.

[VShingala]

@mtaylorfsmb So the Schema for resolution is used toward documentation/reference purposes and Example is more focused on value that actually follows schema defined in API definition.

Also you need not to define examples for each schema, Example option will use schema faker to generate fake data based on schema when example not available.

For example, Generated value will respect all keywords mentioned in OpenAPI spec.

[mtaylorfsmb]

OK, yes the "data faker" isn't too great for my purposes. An example is better but it doesn't seem to respect patterns or enums or other formatted values. But this doesn't have to be perfect so I can live with it as I'm going to have to hand edit the collections anyway.

[VShingala]

@VShingala sorry I was incorrect about path parameters using vars. It doesn't do that, I was just used to doing that. However I tried putting an example on the parameter and it was ignored when it was generated.

 parameters:
      - in: path
        name: value
        required: true
        type: string
        example: "{{value}}"

It generated a random string value.

As for this, the Mentioned example seems incorrect. The below mentioned parameter will achieve what you are trying to do.

in: path
name: value
required: true
schema:
  type: string
  example: "{{value}}"

[mtaylorfsmb]

That was a typo. It doesn't work under the schema for me. It still autogenerates an example value instead. Maybe I'm doing it wrong but I'll look into that later.

[mtaylorfsmb]

I think I figured out the issue with the example. The type I'm using for this parameter is backed by a schema object. That schema object's example is taking priority over the explicit example given in the parameter. This is not good for my purposes but might make sense for others. In my word "closer" examples should take precedence over schema examples.

[mccannt]

@mtaylorfsmb Just checking in here. Sounds like this issue is now resolved, can you confirm?

[CoolDadTx]

I don't believe it is correct but it is working. Schema examples are taking priority over examples directly in the parameter. So if I define a schema to back a complex string type and put an example on it then that example takes precedence over the example tag that might be placed on the actual parameter. As I mentioned in my last post I believe "closer" examples should take precedence over schema examples.

A schema example is demonstrating the type. A parameter example is demonstrating a reasonable value for that parameter. Different parameters, of the same type, may have different examples depending upon the endpoint.

[VShingala]

@CoolDadTx @mtaylorfsmb I think mentioned behaviour by you makes more sense, where the more "closer" (or "outer") example should take precedence. In this case, example of parameter object will take precedence over example present in schema. Actually, the behaviour is already followed for request/response content type objects. We will try to update this for parameters objects as well.