code-server: Unable to write to Folder Settings because no resource is provided.

Chiming in to say I have the same experience every time I refresh the IDE window on a different OS. Code-Server is hosted in a container by Unraid.

• Web Browser: chrome
• Local OS: chromeOS
• Remote OS: Unraid
• Remote Architecture: docker
• code-server --version: 3.11

@jsjoeio that’s some incredible detective work. Incredible 👏🏻

@jsjoeio This appears to resolve the notification! I haven’t seen it come back in existing directories. 🎉

I noticed at the same time as I the “Unable to write…” notification, when I navigated to subdirectories which did not exist, behavior changed from: “automatically create the subdirectory” to the familiar message “Unable to write to folder settings…”

Now I get the following response:

Unable to open ‘new_subdir’: Unable to read file ‘vscode-remote://code.domain.com/config/workspace/dir/new_subdir’ (Error: Unable to resolve non-existing file ‘vscode-remote://code.domain.com/config/workspace/dir/new_subdir’).

And it asks if I’d like to create the directory.

Sounds like a much better behavior, IMO!

---

However, there still exists a semi-related error on my end where Jupyter Notebooks aren’t rendering… See #3874

@caochuansong @djasonweiser @aryasenna @wjziv can one of you confirm that this fixes it?

Solution

1. Open Command Palette
2. Open "Preferences: Open Settings (JSON)
3. Look for “workbench.editorAssociations”
4. Change it to this:

"workbench.editorAssociations": {
    "*.ipynb": "jupyter.notebook.ipynb"
},

And let me know if that fixes it?

I’m starting to work on this and taking notes here. I’ll update this message as I go so I’m not spamming the issue with new comments each update.

Notes

searching for “Unable to write to Folder Settings because no resource is provided” reveals lib/vscode/src/vs/workbench/services/configuration/common/configurationEditingService.ts which has a private method called toErrorMessage and a switch statement to handle each error case.

It looks like this is the key block where VS Code rejects and with this ConfigurationEditingErrorCode.ERROR_INVALID_FOLDER_CONFIGURATION error.

if (!(configurationProperties[operation.key].scope === ConfigurationScope.RESOURCE || configurationProperties[operation.key].scope === ConfigurationScope.LANGUAGE_OVERRIDABLE)) {
	return this.reject(ConfigurationEditingErrorCode.ERROR_INVALID_FOLDER_CONFIGURATION, target, operation);
}

Pulling that apart, it’s an if statement with a single condition check consisting of two checks. configurationProperties[operation.key].scope === ConfigurationScope.RESOURCE and configurationProperties[operation.key].scope === ConfigurationScope.LANGUAGE_OVERRIDABLE.

If either of those evaluate to false then this check fails, causing the rejection with the error.

Time to investigate ConfigurationScope.RESOURCE and ConfigurationScope.LANGUAGE_OVERRIDABLE.

Both belong to the same object: ConfigurationScope.

This value is imported into the file from vs/platform/configuration/common/configurationRegistry.

Looking at lib/vscode/src/vs/platform/configuration/common/configurationRegistry.ts, we see ConfigurationScope is an enum. Here’s what it tells us:

/**
* Resource specific configuration, which can be configured in the user, workspace or folder settings.
*/
RESOURCE,
/**
* Resource specific configuration that can be configured in language specific settings
*/
LANGUAGE_OVERRIDABLE,

So now the question is, where are these resource configuration set? I’m going to search fo LANGUAGE_OVERRIDABLE since I imagine that is less common of a search term and will be easier to find.

It appears in lib/vscode/src/vs/platform/configuration/common/configurationRegistry.ts there is a class which has a private method called updateSchema to set this property.

Hmm…looking around, nothing specific stands out. Let’s move on to RESOURCE

Hmm…still unsure where this could be happening. My guess is VS Code starts up and expects a RESOURCE when registering the configuration. I know in lib/vscode/src/vs/server/server.ts there is a configurationService created. My hunch would be to look there.

I think it makes sense run code-server locally with either the debugger or some console.log statements near the error to continue troubleshooting.

This is strange. I put a console.log on L508 in configurationEditingService but I’m not seeing it logged to the browser or the server 🤔 I think the error is happening elsewhere.

Let’s follow the stack trace up:

at ConfigurationEditingService.reject

so the service calls the reject method which returns Promise.reject with a new message.

at ConfigurationEditingService.resolveAndValidate

adding a console log here to see if we see it. (we do)

going to see if I can use the debugger.

nope, debugger didn’t work.

Okay following the stack trace, looks like we are here:

if (!operation.resource) {
			return this.reject(ConfigurationEditingErrorCode.ERROR_INVALID_FOLDER_TARGET, target, operation);
		}

This means operation.resouce is the culprit 🤔

After logging it, it looks like it’s related to "jupyter.notebook.ipynb". I wonder if this error has to do with the Jupyter extension?

• see if error appears with extension uninstalled

nope, even with extension uninstalled, it still happens.

next step will be to continue up the stack trace until we get to the root of the error.

I feel like I’m hitting a dead-end. Not sure but I found this in the Settings. I wonder if I remove if it will go away.

*.ipynb jupyter.notebook.ipynb

Previously:

    "workbench.editorAssociations": [

      {
        "viewType": "jupyter.notebook.ipynb",
        "filenamePattern": "*.ipynb"
      }
    ],

Wait a second…that made it go away? (I’m no longer seeing the error)

- "workbench.editorAssociations": [
-    {
-       "viewType": "jupyter.notebook.ipynb",
-       "filenamePattern": "*.ipynb"
-     }
- ],
+ "workbench.editorAssociations": {
+    "*.ipynb": "jupyter.notebook.ipynb"
+ },

Yup, adding it back causes the error toast. I think that’s the culprit.

thanks @jsjoeio

Also chiming in to say that this happens to me as well.

• Web Browser: Firefox 90.0.2
• Local OS: MacOS 11.4
• Remote OS: Ubuntu 20.04.2
• Remote Architecture: used the install script?
• Code-server version: 3.11.1

So… This is not only limited to local OS being Mac OS or Chrome only, Windows is also affected.

• Web Browser: Edge
• Local OS: Windows 10
• Remote OS: ubuntu 20.04
• Remote Architecture: AMD64
• code-server --version: 3.11

Oh you were able to reproduce like that? Odd, it didn’t reproduce for me. This couldn’t somehow be related to the local OS being MacOS could it? Seems unlikely.