RPC Raw Stream Errors (distinguish between transport errors and application errors)

[tegefaulkes]

Specification

We need to review how errors are handled for RPC raw handlers. The transport level error handling needs to be reviewed as well. Error handling between websocket streams and QUIC streams need to be stadardized between each other as well.

There needs to be separation between transport level errors and RPC level ones. I think this is already the case.

Additional context

• Related: js-quic integration and Agent migration Polykey#525 (comment)
• Related js-quic integration and Agent migration Polykey#525
• Related: More complex error codes logic for closing WebSocketConnections/WebSocketStreams js-ws#4
• Extract src/websockets from Polykey to js-ws js-ws#1

Tasks

1. ...
2. ...
3. ...

[CMCDragonkai]

When we drop to raw streams, we cannot make use of JSON RPC to transmit errors anymore. If an error were to occur, it has to be done in whatever the raw stream is doing, which depends on the handler managing the raw stream. It could be using CBOR or protobuf... But in some cases, the raw stream is just raw binary data. Say for example uploading a file from Polykey CLI to Polykey Agent. In that situation, if there's an error, it's only possible to send it at the transport level.

Transport level error capability can be limited. In some cases only a numeric code can be transmitted. We should allow for some ability of choosing these codes. A message could be supplied, however if the transport layer doesn't support it, then it just ignores the message.

A generic exception for transport layer errors should then be raised to the other side. It should be possible to distinguish 3 kinds of errors in the transport layer:

1. System level errors
2. Application errors
3. Application due to RPC raw stream errors

Usually 1 and 2 are distinguishable by some sort of code. However 2 and 3 may need an additional code, or a subcode or something.

[CMCDragonkai]

Moved to js-rpc as it would be done there.

[CMCDragonkai]

This can only be done after MatrixAI/js-ws#1 and MatrixAI/js-ws#2 is done first. Because in order to separate 3 levels of errors:

• Connection Errors
• Stream Errors
• RPC Call Errors

The concept of a "stream" needs to exist above a "WebSocket" connection.

For js-quic this is already done due to QUICStream.

[addievo]

• Re-introduce codes which was refactored out and replace them with RPC specific codes instead of PK codes.
• Write specific errors for RPC -> -32000 - -32099
• Implement codes in src.

(Cope concurrent jests get fixed.)

• Implement with toError and fromError.
• Jests?