mschuchard / linter-ansible-linting

ansible-lint linter for pulsar

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Error: Line number (169) greater than maximum line (39)

ssbarnea opened this issue · comments

I don't really know what is causing this but this seems like a critical bug to me. Yes the current file has only 39 lines.

Error: Line number (169) greater than maximum line (39)
    at Object.rangeFromLineNumber (/Users/sorins/.atom/packages/linter-shellcheck/node_modules/atom-linter/lib/index.js:181:11)
    at /Users/sorins/.atom/packages/linter-ansible-linting/lib/main.js:110:32
    at Array.forEach (native)
    at /Users/sorins/.atom/packages/linter-ansible-linting/lib/main.js:105:33

screenshot 2016-03-24 07 59 55

Do you have the ansible file throwing this error?

I am afraid that there is nothing wrong with that file, the error can happen on other files too but is not consistent, making me believe that is happening when a file is updated during linting.
As you can see from the message, it cannot really be a real syntax error with the file at a line greater than max line.

I would recommend on bypassing this error without throwing an exception, log it but dont expose it in the UI, or if you do, make sure is discrete, not a popup dialog that takes 50% of the screen.

Be sure that I will be back if I get more info and maybe identify a clear way to reproduce it. So far is flapping.

The problem appears to be with a function call to the atom linter API with an inaccurate line number possibly due to a bad regex. I would need to at least see the ansible-lint output for the file, but preferably the original ansible file/playbook, in order to debug this.

I am afraid that this kind of error is very hard to replicate and I suspect that it could also be caused by the file activity. How about silencing it? Clearly there is not much use for the end-user of the package for seeing such a problem, which is also intermittent. This is the kind of issue that is supposed to be logged, not displayed to the user.

In that case this was fixed in 5976802 and 560a0ac which were both part of the recent 1.1.2 release.