You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As I'm working on a spec I will see errors pop up (correctly) indicating that I've violated some rule or other. As I update the specification and correct the errors, it appears revalidation still finds those errors. Watching the validation happening in the Spectral output window, I definitely see it finding errors that aren't there anymore.
I can then jump over to my web browser (like now) and, without changing anything, see the Spectral linting get kicked off, like it's a queue of validation requests that have somehow been delayed against stale versions of the document. The "dam broke" and the old requests for validation suddenly started going through but instead of being the latest copy of the document, it's a cached version - the version that was there when the request to lint got kicked off.
That queue logic/explanation sort of makes sense - since that is pretty much how validation gets kicked off. I remember I grabbed that from the (MIT licensed) ESLint plugin implementation and I don't know if perhaps they've figured out some improvements to the mechanism or something since the Spectral extension started.
This seems to happen more with large schemas (e.g., 2700 lines, 20 paths, 50 operations) rather than smaller schemas (maybe 1000 lines, 10 paths, etc.). Unclear if there's a tie between memory usage or schema size and the delay here.
The text was updated successfully, but these errors were encountered:
I've verified that rolling back to 1.1.0 seems to resolve the delay/caching problem. I don't see much that happened between 1.1.0 and 1.1.2 other than some package updates, so something in there is going to be the problem.
Describe the bug
As I'm working on a spec I will see errors pop up (correctly) indicating that I've violated some rule or other. As I update the specification and correct the errors, it appears revalidation still finds those errors. Watching the validation happening in the Spectral output window, I definitely see it finding errors that aren't there anymore.
I can then jump over to my web browser (like now) and, without changing anything, see the Spectral linting get kicked off, like it's a queue of validation requests that have somehow been delayed against stale versions of the document. The "dam broke" and the old requests for validation suddenly started going through but instead of being the latest copy of the document, it's a cached version - the version that was there when the request to lint got kicked off.
That queue logic/explanation sort of makes sense - since that is pretty much how validation gets kicked off. I remember I grabbed that from the (MIT licensed) ESLint plugin implementation and I don't know if perhaps they've figured out some improvements to the mechanism or something since the Spectral extension started.
This seems to happen more with large schemas (e.g., 2700 lines, 20 paths, 50 operations) rather than smaller schemas (maybe 1000 lines, 10 paths, etc.). Unclear if there's a tie between memory usage or schema size and the delay here.
The text was updated successfully, but these errors were encountered: