interagent / interagent/committee

If assert_request_schema_confirm and Committee::Middleware::RequestValidation are used at the same time, date-time validation fails.

Open
#283 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Ruby
Stars
955
Forks
145
Avg merge
5d 4h
Merged PRs (30d)
6

Description

Description

If I use Committee::Middleware::RequestValidation, the date-time conversion is done at the same time as the request is processed.
Then, if I run assert_request_schema_confirm, the conversion is already completed and the validation will fail in the following part
https://github.com/ota42y/openapi_parser/blob/v0.12.1/lib/openapi_parser/schema_validators/string_validator.rb#L11
At this time, the value is already converted to DateTime.

Is this a bug?
If you have any solutions, please let me know.

Environment

ruby 2.7.1
rails 6.0.3.2
committee 4.2.0
rspec 3.9.0

application.rb

config.middleware.use Committee::Middleware::RequestValidation, schema_path: schema_path, parse_response_by_content_type: false

OpenAPI 3.0 yaml

/contents:
  get:
    summary: example
    description: example
    parameters:
      - in: query
        name: q
        description: filtering
        required: false
        style: deepObject
        schema:
          type: object
          description: filtering
          properties:
            start_at_gteq:
              type: string
              description: start_at greater than or equal
              format: date-time
              example: "2019-10-01T00:00:00+9:00"
              nullable: true
            end_at_lteq:
              type: string
              description: end_at less than or equal
              format: date-time
              example: "2019-10-31T23:59:59+9:00"
              nullable: true
    responses:
      "200":
        description: contents list
...

spec

it "foo" do
  get contents_url(q: { start_at_gteq: "2020-01-01", end_at_lteq: "2020-01-31" })
  assert_request_schema_confirm
  assert_response_schema_confirm
  expect(response).to have_http_status(:success)
end

spec result

Committee::InvalidRequest: #/.../schema/properties/end_at_lteq expected string, but received DateTime: 2020-01-31T00:00:00+00:00

  0) ContentsController request spec GET #index ...
     Failure/Error: assert_request_schema_confirm

     Committee::InvalidRequest:
       #/.../schema/properties/end_at_lteq expected string, but received DateTime: 2020-01-31T00:00:00+00:00
     # ./spec/spec.rb:98:in `block (6 levels) in <top (required)>'
     # ------------------
     # --- Caused by: ---
     # OpenAPIParser::ValidateError:
     #   #/.../schema/properties/end_at_lteq expected string, but received DateTime: 2020-01-31T00:00:00+00:00
     #   ./spec/spec.rb:98:in `block (6 levels) in <top (required)>'

screenshot

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the reproduction in spec.rb, using Committee::Middleware::RequestValidation and assert_request_schema_confirm together. Read lib/openapi_parser/schema_validators/string_validator.rb at the referenced validation point and trace how the date-time query value becomes DateTime. Done when the request and schema confirmations handle this combination consistently without the reported type error.

Written by the indexing model from the issue text.

Assessment

Tech stack
ruby
Domain
api
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.