SpacetimeDB Some server errors are not reported to the client

This is a mix of server/protobuf/C# client SDK issues, but I'm sticking them all here for now.

There are three cases I'm aware of:

[x] 1. Malformed Subscribe calls are not reported to the client at all

Repro

In the quickstart dotnet project , replace the line:

SpacetimeDBClient.instance.Subscribe(new List<string> { "SELECT * FROM User", "SELECT * FROM Message" });

with

// this will cause an unreported server error
SpacetimeDBClient.instance.Subscribe(new List<string> { "SELECT * FROM HI MY NAME IS JAMES User", "SELECT * FROM Message" });
// invoking Subscribe again will succeed, and the client will proceed as if nothing has happened
SpacetimeDBClient.instance.Subscribe(new List<string> { "SELECT * FROM User", "SELECT * FROM Message" });

Then spacetime start, spacetime publish chat2 in quickstart/server, and dotnet run in quickstart/client.

Server logs:

2023-08-25T18:19:08.124171Z TRACE crates\client-api\src\routes\subscribe.rs:232: Received heartbeat from client ClientActorId(90cf6f2168def766e073b6bedf063aea07785fd751a625fde7dec9d5d26dde3e/0)
2023-08-25T18:19:08.265946Z ERROR crates\core\src\subscription\module_subscription_actor.rs:66: error occurred in ModuleSubscriptionActor: SqlParserError: sql parser error: Expected end of statement, found: NAME, executing: `SELECT * FROM HI MY NAME IS JAMES User`
2023-08-25T18:19:38.118225Z TRACE crates\client-api\src\routes\subscribe.rs:232: Received heartbeat from client ClientActorId(90cf6f2168def766e073b6bedf063aea07785fd751a625fde7dec9d5d26dde3e/0)

Client logs do not mention this error.

[x] 2. Errors in reducers are reported to the client, but not logged by default in the C# client SDK

Repro

For example, if you run an unaltered quickstart project, wait for a server connection, and then press "enter", the server will reject the message because it's programmed to reject empty messages. The user will be told about this with an Event with status set to failed. However, it isn't logged by default, the user has to dig the error out of the protobuf by hand. This is a pretty easy client-side fix.

[ ] 3. Certain unusual errors can cause the server to close the client websocket, or prevent it from opening in the first place. In the C# SDK, this causes the client to hang with no issue of an error. Both of my repros for this are fairly contrived though.

Repro A: malformed JSON over the websocket

Inline the C# sdk into the C# quickstart project, i.e.:

remove the line <PackageReference Include="SpacetimeDB.ClientSDK" Version="0.6.0" /> from quickstart/client/client.csproj
copy spacetimedb-csharp-sdk/src to quickstart/client/sdk

In the file quickstart/client/sdk/SpacetimeDBClient.cs, change the line

webSocket.Send(Encoding.ASCII.GetBytes("{ \"subscribe\": { \"query_strings\": " + json + " }}"));

to

webSocket.Send(Encoding.ASCII.GetBytes("{ \"subscrib\": { \"query_strings\": " + json + " }}"));

Then spacetime start, spacetime publish chat2 in quickstart/server, and dotnet run in quickstart/client.

Server logs:

2023-08-25T18:42:52.908700Z TRACE crates\client-api\src\routes\subscribe.rs:232: Received heartbeat from client ClientActorId(90cf6f2168def766e073b6bedf063aea07785fd751a625fde7dec9d5d26dde3e/0)
2023-08-25T18:42:53.012411Z DEBUG crates\client-api\src\routes\subscribe.rs:216: Client caused error on text message: 
unknown variant `subscrib`, expected one of `call`, `subscribe`, `one_off_query` at line 1 column 12
2023-08-25T18:42:53.018879Z TRACE crates\client-api\src\routes\subscribe.rs:247: Close frame Some(CloseFrame { code: Normal, reason: "" })
2023-08-25T18:42:53.020439Z DEBUG crates\client-api\src\routes\subscribe.rs:251: Client connection ended

Note that the close frame comes from the client, not the server! This means that the server must have told the client to terminate the connection somehow. None of this is visible in the client logs.

Repro B: server has fresh certificates, old authtokens are rejected

delete ~/.spacetime
spacetime identity remove --all --force
in quickstart/server, spacetime publish chat2
in quickstart/client, dotnet run

The server will log a rejected JSON web token:

2023-08-25T19:18:41.090945Z TRACE crates\client-api\src\auth.rs:149: Authorization rejection: Jwt(InvalidSignature)

but the client receives no indication of this.

On further reflection, I'm not sure 3 is worth fixing. 1 and 2 are relatively easy. 3 has more to do with malformed handshakes and low-level protocol messages, which aren't things that are very user-facing.

I guess it might be worth adding a generic ProtocolError protobuf, which would work for 3A. I have no idea about 3B.

Aug 25 '23 19:08 kazimuth