[json] problem from unaccessible schema is distracting

[Tyriar]

I was on a plane without internet working and this popped up in the tsconfig.json. A silent failure would have been better in this case as I know I don't have internet:

Problems loading reference 'https://schemastore.azurewebsites.net/schemas/json/tsconfig.json': Unable to load schema from 'https://schemastore.azurewebsites.net/schemas/json/tsconfig.json': Unable to connect to https://schemastore.azurewebsites.net/schemas/json/tsconfig.json. Error: connect ETIMEDOUT 168.62.224.13:443

[aeschli]

Why do you think it is a bug? What do you suggest as improvement?

[usernamehw]

Caching tsconfig.json schema?

[Tyriar]

Why do you think it is a bug? What do you suggest as improvement?

1. I'm not sure why I got the error in the first place as the schema should have been cached.
2. The main thing is to not show an error that cannot be dismissed just because I don't have an internet connection. I know I don't and I want to code on the plane without needless distractions that cannot be actioned. A console.error would be more appropriate.

[aeschli]

Yes, schemas are cached, but we are pretty aggressive in reseting the cache for example on json settings changes. One reason for that is also that the server data can update any time.

What you get is a problem of severity information in the problems view. I personally don't find it very distractive but rather important information that explains why you don't get any validation and code assist on this file. Connectivity is one reason, but you might also have mistyped the URL or have proxy issues. Just logging that to the dev console is IMO not the right thing to do. The typical user doesn't have the dev tools open.

I'm happy to keep this request open for votes from other users.

[Tyriar]

I personally don't find it very distractive but rather important information that explains why you don't get any validation and code assist on this file.

I use F8 frequently to fix all errors in the project before committing, it's annoying that tsconfig.json keeps opening with an error that I cannot be "fixed".

Connectivity is one reason, but you might also have mistyped the URL or have proxy issues.

Wouldn't these return different error messages and can be handled separately?

[Tyriar]

What I saw on the next flight:

[ramya-rao-a]

@aeschli Having a non-actionable error/warning that cannot be removed is indeed distracting. Having a setting that controls this attempt to refresh the schema cache can help in 2 ways

• When users are offline, they can now turn this feature off and have no distractions
• As per Offline mode for VS Code #54354, users who want to control outgoing network requests from VS Code now can control the schema check.

Thoughts?

[Tyriar]

@ramya-rao-a a setting is all good and fine, but I don't want to go and manually change a bunch of settings when I'm offline for a while just to avoid online-related error message. It should silently fail and use a cached copy if no network is detected as having the absolute latest schema version isn't critical to operation.

[Ntropish]

Slightly related, I get the same thing except it's trying to load the package.json schema. I work in a closed environment so that schema is never going to be loaded. I also like to use the built-in console as I develop so I always see "Problems (1)".

[Tyriar]

@aeschli is this a good candidate for help wanted/good first issue?

[aeschli]

Yes, good idea.
I was thinking we add a status bar entry for JSON like for TypeScript or TSLint. That can all be done on the JSON client. Write a middleware that intercepts the diagnostics from the server, filter the SchemaResolveError, create a status bar entry.

[literalplus]

If this is what you mean by "create a status bar entry", then I'd like to try to solve this issue:

[aeschli]

I meant something like what TSLint shows:

There can be a hover on the status item explaining that validation for the current file is disabled as the schema could not be resolved.
Clicking on it can offer a retry action (that would likely require a new type of message that we send to the JSON server).

[aeschli]

fixed by #60219