Search code examples
javaregexjerseyopenapiswagger-editor

OpenAPI 3 Validation Error : should match format "regex"


I generated an openapi json spec from a Jersey RestApi code I wrote, and one of the constraints I have is a regex negative-lookahead pattern for "LEAGUE-MEMBER" request header. When I convert the json into yaml like so.

openapi: 3.0.1
info:
  title: Justice League Delegate Admin Sheet 
  description: 'Log Record for Temp admin access to the WatchTower'
  version: v1
servers:
  - url: https://watchtower.wayne:9443
    description: Generated server url
paths:
  /ent-watchtower-auth/v3/delegate:
    get:
      tags:
        - Search
      summary: Search for a UID
      operationId: searchForUID
      parameters:
        - name: MemberID
          in: header
          required: true
          schema:
            type: string
          example: JL000000
        - name: LEAGUE-MEMBER
          in: header
          required: true
          schema:
            pattern: '^(?!(?i)\bJOKER\b).*$'
            type: string
          example: BATMAN, JON, HAWKGIRL, ORACLE, FLASH, ANYONEBUTJOKER
      responses:
        '200':
          description: The resulting Delegate History

I get the following validation error at swagger.io editor:

Structural error at paths./ent-watchtower-auth/v3/delegate.get.parameters.1.schema.pattern
should match format "regex"
format: regex

For context on the regex, '^(?!(?i)\bJOKER\b).*$' basically allows for any case-insensitive value except 'joker' within the header. (Also, the converted yaml did not wrap the pattern within single quotes, I had to add it later). When I run and test my RESTAPI, the pattern works as expected, and throws ConstraintViolation if the value is "Joker". But I am unable to identify what the editor is trying to call out. Any suggestion and possible fix appreciated, Thank you.

Update: I have pasted MWE for openapi yaml to play around in swagger editor


Solution

  • EDIT 2024-01: The new v5 Swagger Editor no longer reports validation errors for this.


    We ran into the same situation. It seems the spec validator doesn't recognize mode flags like (?i) as valid regex. In our case we worked around it by specifying the mode separately from the expression in the field annotation:

    @Pattern(regexp = "^etc$", flags = Pattern.Flag.CASE_INSENSITIVE)

    Which was okay for our situation but not ideal, since it doesn't communicate the entire requirement to the spec consumer.