quickstart-chat issues with Claude Code

[capncleaver]

Ahoy! Very interesting tool, excited to try it out Claude Code and I tried to install the quickstart-chat app, vanilla.

It was fiddly business, we got there in the end (took ~one instance worth of context.) Here's CC's writeup, I hope this is useful.

In particular I noticed the version depenency was wrong for the rust-client (first attempt, aborted) and I think the quickstart-chat. Given that quickstart-chat is a rust client, the presence of both is confusing but quickstart seems the more recent.

Getting SpacetimeDB Quickstart-Chat Working: The Ideal Path

Here's a summary of the steps needed to get the SpacetimeDB quickstart-chat example working, following the most direct path:

1. Setting up the proper Rust environment

# Install Rust with rustup (not Homebrew) to ensure proper WebAssembly support
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y --default-toolchain 1.84.0 --profile default --target wasm32-unknown-unknown

# Add WebAssembly target support
rustup target add wasm32-unknown-unknown

2. Installing and running SpacetimeDB

# Install SpacetimeDB CLI
curl -sSf https://install.spacetimedb.com | sh

# Add SpacetimeDB to PATH
export PATH="$HOME/.local/bin:$PATH"

# Start SpacetimeDB in the background
spacetime start > /tmp/spacetime.log 2>&1 &

3. Publishing the module

# Navigate to the quickstart-chat module directory
cd modules/quickstart-chat

# Build and publish the module
spacetime publish --server http://127.0.0.1:3000 --anonymous chat-demo

4. Building and running the client

# Create a directory for the client
mkdir -p quickstart-chat-client/src

# Copy the module bindings
cp -R modules/quickstart-chat/module_bindings quickstart-chat-client/src/

# Create Cargo.toml with proper dependencies
cat > quickstart-chat-client/Cargo.toml << EOF
[package]
name = "quickstart-chat-client"
version = "0.1.0"
edition = "2021"

[dependencies]
spacetimedb-sdk = "1.0.1"
EOF

# Create main.rs with the client code, using the correct module name
# (Key point: The with_token handling should be optional for first-time users)

# Build and run the client
cd quickstart-chat-client
cargo run

Feedback for SpacetimeDB developers

1. Rust installation instructions: The documentation should emphasize that rustup (not Homebrew Rust) is required for proper WebAssembly support, with specific instructions for the target.

2. Client authentication handling: The example should better handle first-time connections without credentials. Currently, it uses .expect() which causes errors for new users.

3. Module ownership and permissions: We encountered several permission errors when trying to republish or update modules. A clearer ownership model or easier way to manage modules for development would be helpful.

4. Non-interactive client options: The example could benefit from a non-interactive mode for testing, as interactive terminal input can be challenging in some environments.

5. Better error messages: When the server isn't running, the client error messages could be more clear about connection issues.

6. Documentation for common operations: More examples for common tasks like listing databases, checking status, deleting, and updating modules would be helpful.

7. WebAssembly optimization warnings: The warning about missing wasm-opt is confusing for beginners. Either include it or make the warning less prominent.

8. Consistent API across language SDKs: Ensure authentication and connection patterns are consistent across different SDKs.

9. Offline development mode: A simpler local development experience that doesn't require authentication would help developers get started more quickly.

[capncleaver]

I followed the instructions and got it working myself, np. Score one for team human!

I do think putting a quickstart guide for AI in the repo docs is a good idea for us game designer muppets who want to vibe our way to the next MMO (or have fun crashing against the context limit trying!) Rust and Spacetime look v promising for this as they are very simple and the code is tiny relative to js / ts twisty maze esp.

[bfops]

Thanks for following up! I'm glad that the instructions were easy to follow for a human.

We do have plans to improve our AI-readability though!

We also created these issues:

• Docs - Clarify that only the user who published a module can overwrite it #3083
• CLI - Improve error message when target server isn't running #2545
• Docs - Clarify that rust should be installed via rustup, not homebrew #3081

Some folks from the dev team also had this to say about the expect piece:

Claude is wrong about the expect call in with_token. From the doc comment of spacetimedb_sdk::credentials::File::load:

Returns Err if I/O fails,
None if credentials have not previously been stored,
or Some if credentials are successfully loaded from disk.
After unwrapping the Result, the returned Option can be passed to
[super::DbConnectionBuilder::with_token].

Note that the return type of that method is Result<Option<String>, CredentialFileError>.

[chrisjd20]

It would be nice if the quickstart for typescript as rust was made into some code I could pull down ready to go. Preferably in docker compose.

[bfops]

@chrisjd20 A complete TypeScript quickstart client is here: https://github.com/clockworklabs/spacetimedb-typescript-sdk/tree/main/examples/quickstart-chat. Is that what you're looking for? (It's compatible with either a Rust or C# quickstart-chat server modules, but we don't have server-side support for TypeScript.. yet).

[chrisjd20]

@bfops thanks I didnt realize that existed. I managed to get it from build to run into a single docker compose as I was suggesting (server and client both built and running):

https://github.com/chrisjd20/spacetimedb-chat-quickstart-example

[BenediktKarl]

I tried following the tutorial at https://spacetimedb.com/docs/tutorials/chat-app. But I kept getting this error when trying to publish to my local database:
Error: Pre-publish check failed with status 401 Unauthorized: TokenError(Error(InvalidSignature))
Even though I used the exact template and followed the instructions (commands and code) to the letter. For anyone encountering the same issue: passing --anonymous fixed it for me (like in step 3 of original post).

(The above is not related to Claude Code or other LLMs, but for anyone else trying this and maybe ending up here by searching)

[bfops]

@BenediktKarl that error means that the login token is likely for a different server. Can you try running spacetime login? --anonymous shouldn't be necessary, and it will essentially disown the published database since it will be owned by a temporary user rather than by the person running the command.

[homersimpsons]

But I kept getting this error when trying to publish to my local database:
Error: Pre-publish check failed with status 401 Unauthorized: TokenError(Error(InvalidSignature))

For the record I also often face this issue I successfully resolved it sometimes, but that is always unclear how to do. I run a local instance (whether on my machine or with docker). It seems that every spacetime dev tries to create the credentials the first time but this does not seem to always work if the db was re-started and lost its state.

I cannot seem to find a way to say to my local database either "accept any connection I'm in dev" or "forget about any previous identity and accept a new one" or similar ...

I also observed this message recently :

Uploading to http://127.0.0.1:3000 => http://127.0.0.1:3000
Checking for breaking changes...
Error: Pre-publish check failed with status 403 Forbidden: c20055855f65e0f01b3af67e7fc82a0bb093de915e09c99bd76dd7bec40e9b95 is not authorized to perform action on database c200208dfc49a5f4be6b8560d315950e325ad51f96faa8b31b6a3d9c09a11885: update database

I tried to run an instance that always forgets everything so it does not store any state when I kill it but I still observe those errors:

docker run --rm --publish 3000:3000 clockworklabs/spacetime start --non-interactive --in-memory

[bfops]

@homersimpsons for the failed pre-publish check error: are you ever running things with --anonymous or --server-issued-login?

for the invalid token error: do you ever clear your server config directory? (for me, that's ~/.config/spacetime)

[homersimpsons]

are you ever running things with --anonymous or --server-issued-login?

I did not knew about those. I'm not sure if I'm supposed to run this with the start or with the dev. It looks like I can run spacetime dev -- --anonymous but it leads to the same issue, if I run spacetime dev -- --server-issued-login I have an error that this arbument does not exist.

Edit: just found that spacetime login --server-issued-login 127.0.0.1:3000 allows me to publish on my local spacetime start instance. That said it looks like I still have issues with docker (and traefik), I'm able to perform login but then I have an error when starting dev:

Error: Log streaming error: c2007...4b0 is not authorized to perform action on database c2003fb...396a: view modile logs

I will go on with a local (non dockerized) intance for now.

for the invalid token error: do you ever clear your server config directory? (for me, that's ~/.config/spacetime)

I never touched this repository. I see there is a cli.toml with some configs and a pair of id_ecdsa keys inside. Am I supposed to do anything here?

[bfops]

Hi @homersimpsons, sorry for the delay. I'm definitely not recommending --anonymous or --server-issued-login - I think those will cause more issues like this, which is why I was curious if you were using them.

It seems that every spacetime dev tries to create the credentials the first time

Are you saying it tries to create the credentials every time because of the errors you're seeing, or because it's printing something that suggests it's creating fresh credentials each time?

When you log in, does it open a spacetimedb.com page in your browser?

I never touched this repository. I see there is a cli.toml with some configs and a pair of id_ecdsa keys inside. Am I supposed to do anything here?

You shouldn't need to touch the files in there. I was curious if you were clearing them.

I tried to run an instance that always forgets everything so it does not store any state when I kill it but I still observe those errors

That's interesting and seems like a clear path to a repro. What exactly are you doing to cause the errors in this case?

Thank you for helping us debug this! I do think your description has helped us find one bug that I'll open a PR for, but I think there is still something else going on that's causing issues for you.

[bfops]

Oh one more question, when spacetime dev prompts whether you want to log in with spacetimedb.com, do you enter yes or no?