Uncaught Error: invalid keyPath

[shockey]

This spec:

swagger: '2.0'
info:
  description: >-
    This is a sample server Petstore server.  You can find out more about    
    Swagger at [http://swagger.io](http://swagger.io) or on [irc.freenode.net,
    #swagger](http://swagger.io/irc/).      For this sample, you can use the api
    key `special-key` to test the authorization     filters.
  version: 1.0.0
  title: Swagger Petstore
  termsOfService: 'http://swagger.io/terms/'
  contact:
    email: apiteam@swagger.io
  license:
    name: Apache 2.0
    url: 'http://www.apache.org/licenses/LICENSE-2.0.html'
host: petstore.swagger.io
basePath: /v2
tags:
  - name: pet
    description: Everything about your Pets
    externalDocs:
      description: Find out more
      url: 'http://swagger.io'
  - name: store
    description: Access to Petstore orders
  - name: user
    description: Operations about user
    externalDocs:
      description: Find out more about our store
      url: 'http://swagger.io'
schemes:
  - http
paths:
  /pet:
    post: null # <---------- null causes the error

causes a Uncaught Error: invalid keyPath error, which kills the React lifecycle. Refresh and load of a different spec is required to avoid.

This is especially bad for the Editor.

The error is originating here.

[shockey]

cc @webron

[webron]

Thanks @shockey. FWIW, null is not a valid value anywhere in the spec.

[shockey]

@webron rightly so! Apologies, my initial description wasn't abundantly clear. There's a combination of things at work here:

1. blank YAML values are translated to null for representation in JS. Consider this:

paths:
  /pet:
    post: 

The resulting JS object (or JSON even) would be:

{
  "paths": {
    "/pet": {
      "post": null
    }
  }
}

You'd never actually publish this in a spec (I hope), but this would be a common place to pause when you're handwriting a spec, so this mostly affects the Editor, in practice.

When we try to grab the operation at paths.pets.post for rendering, we get null back. That's not ideal, but harmless, except for the fact that....

2. We assume elsewhere, that when we query a valid position at paths.[path].[method] in the spec, we'll get an object back.

Here is the culprit, as I mentioned earlier. The big problem is that this code is in a reducer, which is not covered under our React try/catch guard. So, when the error throws, it blows up the app's lifecycle, which requires a page refresh to fix.