Mock response contains random fields

[zkorhone]

Context

Generated mock response does not follow schema

Current Behavior

Given OpenAPI doc:

openapi: 3.0.3
info:
  title: Subscription Query API
  version: '1.0'
  description: Unified interface for querying Subscriptions A and B
servers:
  - url: 'http://localhost:3000/subscription-queries'
paths:
  /active_subscriptions:
    get:
      summary: Get active subscriptions
      tags: []
      responses:
        '200':
          description: OK
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/ActiveSubscription'
      operationId: get-active_subscriptions
      description: Get list of active subscriptions
      parameters:
        - schema:
            type: boolean
          in: query
          name: module_support
          description: 'When true return subscriptions that could theoretically have modules. When false or undefined, do not filter result set'
components:
  schemas:
    ActiveSubscription:
      title: ActiveSubscription
      type: object
      description: Active Subscription
      x-examples: {}
      x-internal: false
      properties:
        actions:
          type: object
          description: Actions available for caller
          properties:
            availableModules:
              type: string
              description: Allowed to query for available modules

Prims generates response:

[
  {
    "actions": {
      "availableModules": "ex",
      "dolore_3d4": -18659865,
      "in_aa3": false
    }
  },
  {
    "actions": {
      "availableModules": "irure aliqua Ut",
      "irure_f_": 13851100.013715371,
      "in_d3": "exercitation tempor nisi esse et",
      "nullaca3": 24122535.056890324,
      "esseb62": -46474555
    },
    "exercitationec_": 68917320.29432371
  },
  ....

Expected Behavior

Prism generates response that follows specification:

[
  {
    "actions": {
      "availableModules": "ex",
    }
  },

Possible Workaround/Solution

None

Steps to Reproduce

Start Stoplight Studio, open provided OpenAPI document & use Try it against Mock Server

Environment

• Version used: Stoplight Sutdio 2.8.0-stable.7492.git-69a3957 (please make this easier to copy+paste!)
• Environment name and version (e.g. Chrome 39, node.js 5.4): -
• Operating System and version (desktop or mobile): Windows 10 (Desktop)
• Link to your environment/workspace/project: -

[sreenadh-farmface]

I also got this. this happens when there is only one key in the response. just adding another key will fix the issue. An issue that needs to be fixed

[zkorhone]

Not sure if root cause it this, but it seems like json-schema-sampler is using global variables. If generator at any point is called in parallel (e.g. pipe), it might just generate unexpected result

[chohmann]

Could you check that your usage of additionalProperties is configured correctly as mentioned in https://github.com/stoplightio/prism/issues/1157?

The following is something we plan to look into:

this happens when there is only one key in the response. just adding another key will fix the issue.

[williamj20]

Interesting, I didn't know this was a thing! Is there any way I can specifiy additionalProperties = false for all the generated api responses, instead of having to add it to each api doc?

[ryotrellim]

Todo: Let's add an additionalProperties override as a CLI parameter so that it doesn't have to be defined in every schema.

[ryotrellim]

Hey team! Please add your planning poker estimate with Zenhub @chohmann @EdVinyard @daniel-white @brendarearden

[DawidOskwarek]

Out of curiosity, any estimate when this will be resolved?

[chohmann]

@DawidOskwarek There is no estimate available at this time. We do welcome PRs! As a reminder, there is a workaround to set additionalProperties to false in your spec.

[EdVinyard]

An approach that requires no changes to either Prism or your OpenAPI document is add JSON Schema faker options to your file "just in time" using a tool like jq or yq.

For example, with the spec from the original example in a file named original.yaml you can use yq to add global JSON Schema faker options like this:

% yq '. += {"x-json-schema-faker":{"fill-properties":false}}' original.yaml > prism_input.json
% prism mock -d prism_input.json

Or you can store your faker options in a separate file and combine them just before you start Prism:

% yq -s '.[0] * .[1]' original.yaml faker_options.json > prism_input.json
% prism mock -d prism_input.json

where faker_options.json contains

{
  "x-json-schema-faker": {
    "fill-properties": false
  }
}

And if your OpenAPI documents are always YAML, you can do this even without jq:

% cat original.yaml faker_options.yaml > prism_input.yaml
% prism mock -d prism_input.yaml

where faker_options.yaml contains

x-json-schema-faker:
  fill-properties: false

[chohmann]

This will be released in a couple weeks, after we get in some more planned bug fixes.

[chohmann]

This has been released in version 5.3.0.

[DawidOskwarek]

Are we sure this was fixed? I'm on version 5.3.1 and still seeing the same 🤔 @chohmann Unless I'm doing something silly?? Is there any extra configuration needed on my end to get this working?

EDIT: Was looking at the PR that was merged to fix this, and it mentions that this needs to be set in the openapi spec x-json-schema-faker: fillproperties: false

However, the problem still exists even when the above is set.

EDIT2: I can see this working in the CLI when the flag is passed, but not when the values are set in the open api spec.

Also, could this be set in the createServer function possibly for people that are using an API of prism? It could be very beneficial

[juan-belmonte]

I already asked about this in the PR, but probably it wasn't the appropriate place.

@chohmann is it possible to have a new official Docker image with this change — or version 5.3.1 — for those using the official Prism Docker image like I do?

Thank you very much!

[EdVinyard]

@DawidOskwarek and @juan-belmonte , if you're still seeing a problem with this, or have experienced other problems, please open a new issue. We generally don't monitor closed issues.