Failed to write to 'state.settings'. options.stream must be readable.

[Dark Cyber]

Hi All,

I'm facing issue which Failed to write to 'state.settings'. options.stream must be readable. message shown in Cloud9 web interface which annoy me, also that error message shown in my terminal that run server.js.

I have already create state.settings file in c9 workspace and .c9 folder and set it to world writable but still, I got same error message.

So do you know why these thing happen to me, and what I supposed to do in order to fix it?

Thanks

[aglennquicket]

I'm not part of the project, but I fixed this myself from switching from node version 14 to 12.

[floeck1706]

I have the same problem. I already auth the complete folder structure of .c9, c9sdk and the workspace but nothing works. I can't save files in the web editor. Does anyone has a solution for it?

[Jack Morris]

@aglennquicket's answer fixed this issue for me! here's the concrete steps I took:

1. quit c9
2. use nvm to downgrade from node 14 to 12: nvm install 12
3. restart c9

voíla!

[drmrbrewer]

@jxmorris12 @aglennquicket Any way of solving this without having to downgrade from node 14 to 12? Eventually this solution will no longer work.

[Remy Willems]

Have you considered installing Node 12 in a custom directory and starting Cloud9 using that, while upgrading the global Node installation to whichever version you prefer?

[john-perks]

I ran into this problem a couple of days ago, and think I've got to the bottom of it...

Short version: the use of .hasOwnProperty("readable") (and similarly for "writable") in vfs-socket/consumer.js and vfs-socket/worker.js are over-strict; as of Node 14, these properties are getters on the prototypes of Readable and Writable. This means that e.g. an IncomingMessage is no longer recognized by c9 as being readable, so that property is not set on the created token. Replacing those .hasOwnProperty() calls on the various stream and token variables in those files with a simple in operator check appears to fix this.

Longer version: If you compare the last v13 version of stream.Readable with the first v14 version, you'll see the readable flag is no longer set in the constructor, but defined as a getter/setter; the equivalent is done on Writable, which in turn necessitates some handling of it in Duplex. For whatever reason (The fake-multiple-inheritance trick of overriding this[Symbol.hasInstance]() not being available in Node at the time? A deliberate decision to prefer composition over inheritance?), both the the streams stored and created in vfs-socket are tested for their supported behaviour via values of flags rather than types. There are a bunch of places in c9 where a Stream is directly instantiated and readable/writable flags set on it, rather than creating a Readable etc.

Thing I'm not sure about: What was the motivation for insisting that these flags had to be own properties at the time, and does allowing inherited properties as well break it? It seems odd that the code in storeStream() will happily check the value of stream.readable and only later check if readable is an own property or not. Perhaps this was a valid concern for the Stream API in the version of Node it was originally written against, but may not apply anymore?

[drmrbrewer]

@john-perks do you know what the solution is?

[john-perks]

@drmrbrewer As I mentioned above, you need to update the mentioned vfs-socket files to replace stream.hasOwnProperty( "readable") with ("readable" in stream), and likewise for "writable". Maybe do the same for the various token variables too.