Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Cannot read property 'type' of null when linting OpenAPI files #180

Closed
distortedsignal opened this issue Jul 23, 2020 · 7 comments
Closed

Cannot read property 'type' of null when linting OpenAPI files #180

distortedsignal opened this issue Jul 23, 2020 · 7 comments
Assignees
@mkistler
Labels
validation

Comments

@distortedsignal
Copy link
Contributor

I'm the same guy from this issue, this is a problem with a different Open API file.

My team is changing over to Open API 3.0 documentation from RAML, and I'm trying to build up a linter from this tool. Our API is (fairly) complex and our data structures are deeply nested. I recently ran into an issue where one of our *.json files couldn't be linted because of a type deref on a null.

Local information

Installed via npm with the -g flag.

In the directory that I'm linting:

> lint-openapi -v
0.28.0

The call that makes the error happen, and output:

> # Source filename on following line changed to protect the guilty.
> lint-openapi --debug openapi_2.json

[Error] There was a problem with a validator.
Cannot read property 'type' of null

TypeError: Cannot read property 'type' of null
    at arrayOctetSequences (/usr/local/lib/node_modules/ibm-openapi-validator/src/plugins/utils/findOctetSequencePaths.js:38:20)
    at findOctetSequencePaths (/usr/local/lib/node_modules/ibm-openapi-validator/src/plugins/utils/findOctetSequencePaths.js:22:34)
    at /usr/local/lib/node_modules/ibm-openapi-validator/src/plugins/utils/findOctetSequencePaths.js:67:14
    at Array.forEach (<anonymous>)
    at objectOctetSequences (/usr/local/lib/node_modules/ibm-openapi-validator/src/plugins/utils/findOctetSequencePaths.js:53:35)
    at findOctetSequencePaths (/usr/local/lib/node_modules/ibm-openapi-validator/src/plugins/utils/findOctetSequencePaths.js:24:34)
    at /usr/local/lib/node_modules/ibm-openapi-validator/src/plugins/utils/findOctetSequencePaths.js:67:14
    at Array.forEach (<anonymous>)
    at objectOctetSequences (/usr/local/lib/node_modules/ibm-openapi-validator/src/plugins/utils/findOctetSequencePaths.js:53:35)
    at findOctetSequencePaths (/usr/local/lib/node_modules/ibm-openapi-validator/src/plugins/utils/findOctetSequencePaths.js:24:34)

I feel like this is pretty hard to debug because the file splay of our API documentation means that I'm not entirely sure where this error is being hit. Would it be possible to print the name of the file (or, even better, the name of the object/path of the object) that procs the error?
@mkistler
Copy link
Contributor

At the point of this processing, I don't believe we have a filename to print. This code is operating on a resolvedSchema, meaning a schema where references have already been resolved.

But there may be a clue that can help find the problem. The code that failed looks like this:

  const arrayPathsToOctetSequence = [];
  const arrayItems = resolvedSchema.items;
  if (arrayItems !== undefined) {
    // supports both array and string (delimited by .) paths
    const pathToSchema = Array.isArray(path)
      ? path.concat('items')
      : `${path}.items`;
    if (arrayItems.type === 'string' && arrayItems.format === 'binary') {

The last line is the line that failed, attempting to reference type of arrayItems. You see just above that the code checks arrayItems !== undefined, but does not check for null. So this suggests that somewhere in your API doc there is an items: null. Maybe. Worth looking for.

distortedsignal added a commit to distortedsignal/openapi-validator that referenced this issue Aug 27, 2020
@distortedsignal
Show path to erring element on exception
07a0529 
Recently, I ran across an issue where [if the validator throws an
exception in a specific part of the code, the path to the
exception-causing code is swallowed](IBM#180).

After a moderate amount of digging, I decided that an
option for providing more information about this code
would be to put the path to the problematic element or
elememnts into the exception message. This exception
message is displayed whenever the code crashes out. So,
for example, the previous error message output by
lint-openapi was the following:

```
Validation Results for epic_tenant.json:

[Error] There was a problem with a validator.
Cannot read property 'type' of null

TypeError: Cannot read property 'type' of null
    at arrayOctetSequences (/usr/local/lib/node_modules/
                             ibm-openapi-validator/src/
                             plugins/utils/
                             findOctetSequencePaths.js:39:20)
    at findOctetSequencePaths (/usr/local/lib/node_modules/
                             ibm-openapi-validator/src/
                             plugins/utils/
                             findOctetSequencePaths.js:22:34)
    at /usr/local/lib/node_modules/ibm-openapi-validator/
                             src/plugins/utils/
                             findOctetSequencePaths.js:72:14
    at Array.forEach (<anonymous>)
    at objectOctetSequences (/usr/local/lib/node_modules/
                             ibm-openapi-validator/src/
                             plugins/utils/
                             findOctetSequencePaths.js:58:35)
    at findOctetSequencePaths (/usr/local/lib/node_modules/
                             ibm-openapi-validator/src/
                             plugins/utils/
                             findOctetSequencePaths.js:24:34)
    at /usr/local/lib/node_modules/
                             ibm-openapi-validator/src/
                             plugins/utils/
                             findOctetSequencePaths.js:72:14
    at Array.forEach (<anonymous>)
    at objectOctetSequences (/usr/local/lib/node_modules/
                             ibm-openapi-validator/src/
                             plugins/utils/
                             findOctetSequencePaths.js:58:35)
    at findOctetSequencePaths (/usr/local/lib/node_modules/
                             ibm-openapi-validator/src/
                             plugins/utils/
                             findOctetSequencePaths.js:24:34)
```

After this change, the output should be the following:

```
[Error] There was a problem with a validator.
items.type and items.format must resolve for the path "paths/my/datatype/path/etc/etc"

TypeError: Cannot read property 'type' of null
    at arrayOctetSequences (/usr/local/lib/node_modules/
                            ibm-openapi-validator/src/
                            plugins/utils/
                            findOctetSequencePaths.js:39:22)
    (same stack as above, I would rather not edit it again)
```

Obviously this commit needs some help with unit testing. I would
like to submit the PR first and then get feedback from the
maintainer on how much testing is needed for this change.
distortedsignal added a commit to distortedsignal/openapi-validator that referenced this issue Aug 27, 2020
@distortedsignal
fix(src/plugins/utils/findOctetSequencePaths.js): Show path to erring…
f79dd0b 
… element on exception

Recently, I ran across an issue where [if the validator throws an exception in a specific part of
the code, the path to the exception-causing code is
swallowed](IBM#180). After a moderate amount of digging,
I decided that an option for providing more information about this code would be to put the path to
the problematic element or elements into the exception message. This exception message is displayed
whenever the code crashes out. So, for example, the previous error message output by lint-openapi
would say "Cannot read property 'type' of null", whereas the new error would list the full path to
the type that was causing the exception.

re IBM#180
@distortedsignal distortedsignal mentioned this issue Aug 27, 2020
Merged
distortedsignal added a commit to distortedsignal/openapi-validator that referenced this issue Aug 27, 2020
@distortedsignal
fix(src/plugins/utils/findOctetSequencePaths.js): Show path to erring…
f9f0253 
… element on exception

Recently, I ran across an issue where [if the validator throws an exception in a specific part of
the code, the path to the exception-causing code is
swallowed](IBM#180). After a moderate amount of digging,
I decided that an option for providing more information about this code would be to put the path to
the problematic element or elements into the exception message. This exception message is displayed
whenever the code crashes out. So, for example, the previous error message output by lint-openapi
would say "Cannot read property 'type' of null", whereas the new error would list the full path to
the type that was causing the exception.

re IBM#180
distortedsignal added a commit to distortedsignal/openapi-validator that referenced this issue Oct 8, 2020
@distortedsignal
fix(src/plugins/utils/findOctetSequencePaths.js): Show path to erring…
c4e4f20 
… element on exception

Recently, I ran across an issue where [if the validator throws an exception in a specific part of
the code, the path to the exception-causing code is
swallowed](IBM#180). After a moderate amount of digging,
I decided that an option for providing more information about this code would be to put the path to
the problematic element or elements into the exception message. This exception message is displayed
whenever the code crashes out. So, for example, the previous error message output by lint-openapi
would say "Cannot read property 'type' of null", whereas the new error would list the full path to
the type that was causing the exception.

re IBM#180
@distortedsignal
Copy link
Contributor Author

I was just about to tag somebody in the PR, but I see that there is activity on this ticket. I'll hold my peace for now.

@dpopp07
Copy link
Member

dpopp07 commented Oct 14, 2020

@jorge-ibm was @mkistler going to work on this? If not, @distortedsignal, we would welcome the PR!

@jorge-ibm
Copy link
Contributor

Yes I think @mkistler was going to take a look, but I agree. @distortedsignal if you have a PR for this already please feel free to submit it

@distortedsignal
Copy link
Contributor Author

distortedsignal commented Oct 14, 2020 •
edited
Loading

I sent a PR to add the path to the exception text. I figure the best way to report to the user that their OpenAPI spec is not valid is to point them to where the invalid spec is. Check out the PR here: #190

distortedsignal added a commit to distortedsignal/openapi-validator that referenced this issue Oct 20, 2020
@distortedsignal
fix(src/plugins/utils/findOctetSequencePaths.js): Show path to erring…
5510e1a 
… element on exception

Recently, I ran across an issue where [if the validator throws an exception in a specific part of
the code, the path to the exception-causing code is
swallowed](IBM#180). After a moderate amount of digging,
I decided that an option for providing more information about this code would be to put the path to
the problematic element or elements into the exception message. This exception message is displayed
whenever the code crashes out. So, for example, the previous error message output by lint-openapi
would say "Cannot read property 'type' of null", whereas the new error would list the full path to
the type that was causing the exception.

re IBM#180
dpopp07 pushed a commit that referenced this issue Oct 23, 2020
@distortedsignal
fix(findOctetSequencePaths): Show path to erring element (#190)
0247888 
* fix(src/plugins/utils/findOctetSequencePaths.js): Show path to erring element on exception

Recently, I ran across an issue where [if the validator throws an exception in a specific part of
the code, the path to the exception-causing code is
swallowed](#180). After a moderate amount of digging,
I decided that an option for providing more information about this code would be to put the path to
the problematic element or elements into the exception message. This exception message is displayed
whenever the code crashes out. So, for example, the previous error message output by lint-openapi
would say "Cannot read property 'type' of null", whereas the new error would list the full path to
the type that was causing the exception.

re #180
@dpopp07
Copy link
Member

dpopp07 commented Oct 23, 2020

Resolved in #190

@distortedsignal Let me know if that PR doesn't fully resolve the issue. Thanks for the PR!

@dpopp07 dpopp07 closed this as completed Oct 23, 2020
@distortedsignal
Copy link
Contributor Author

I think the PR resolves the issue enough. It will at least tell you where the data types are that are causing the issue. This is as much as can be asked for when dealing with faulty API documentation.

dpopp07 pushed a commit that referenced this issue Oct 23, 2020
@semantic-release-bot
chore(release): 0.31.1 [skip ci]
ca14ca0 
## [0.31.1](v0.31.0...v0.31.1) (2020-10-23)

### Bug Fixes

* **findOctetSequencePaths:** Show path to erring element ([#190](#190)) ([0247888](0247888)), closes [#180](#180)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mkistler mkistler

Labels
validation
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@mkistler @distortedsignal @dpopp07 @jorge-ibm