tcp connection error

[AbhishekDas2000]

I tried recreating the quickstart-chat example as mentioned in https://spacetimedb.com/docs/sdks/rust/quickstart
However when I ran spacetime publish --project-path server quickstart-chat , I got this error

Build finished successfully.
Uploading to local => http://127.0.0.1:3000
Publishing module...
Error: error sending request for url (http://127.0.0.1:3000/v1/database/quickstart-chat)

Caused by:
    0: client error (Connect)
    1: tcp connect error: Connection refused (os error 111)
    2: Connection refused (os error 111)

OS: Ubuntu 24.04.1 LTS x86_64

Not sure if it's relevant:

I have seen this type of errors in other software and those can be fixed by editing the /etc/hosts file as mentioned here https://www.errorsolutions.tech/error/linux-error-111-connection-refused/

[Billzabob]

I am getting the same error

[puttehi]

I have battled with STDB for the past few days to learn it, and I think this might be because you have forgot to do one of two things:

• spacetime login -- You need to login to do anything with STDB servers. There was some (maybe undocumented) flag that allows you to skip real login and use fake local login for testing and development purposes
• spacetime start in a separate terminal -- The spacetime publish command builds the WASM module and uploads it to the server, telling it to change to it (publishes it). If your server is not running in that port, it will not connect.
  • I don't think the docs do this, but definitely start your local server with spacetime start --listen-addr='127.0.0.1:3000' so you don't bind an internet-facing port and depending on your firewall, potentially open your computer up for hackers exploiting potential vulnerabilities in the TSDB server.

In case it helps, I have one terminal open with spacetime start --listen-addr='127.0.0.1:3000' all the time when developing, and when I update backend code, I use the following script to push updates (./update.sh nuke will first wipe out the DB when you are wildly hacking around and cannot get a migration through):

(E: It also does some optimization with the CLI flags to skip unnecessary builds, there is no incremental build brain built into the CLI it seems)

#!/usr/bin/env bash

set -euo pipefail

ARG=${1:-""} # Edit: Fixed bug with no args, I have been only nuking so far :)

STDB_PROJECT_PATH="./path-to-your-server-module"
STDB_MODULE_NAME="what-you-want-to-publish-it-as"
STDB_WASM_PROJECT_RELATIVE_PATH="bin/Release/net8.0/wasi-wasm/AppBundle/StdbModule.wasm"
STDB_TYPESCRIPT_OUTPUT_PATH="where-you-want-to-generate-client-code-bindings"

message () {
    echo "******************************************************"
    echo "$1"
    echo "******************************************************"
}

pushd "$STDB_PROJECT_PATH" > /dev/null || exit 1
    message "Cleaning build files from $(pwd)"
    rm -rf obj bin
    message "Restoring dotnet dependencies"
    dotnet restore
    message "Building SpacetimeDB module from $(pwd)"
    spacetime build
    message "Publishing SpacetimeDB module from $(pwd)/$STDB_WASM_PROJECT_RELATIVE_PATH to local server as $STDB_MODULE_NAME"
    PUBLISH_ARGS=("--server" "local" "$STDB_MODULE_NAME" "--bin-path" "$STDB_WASM_PROJECT_RELATIVE_PATH")
    if [[ "$ARG" == "nuke" ]]; then
        message "NUKE command received! Appending --delete-data."
        PUBLISH_ARGS+=("--delete-data")
    fi
    spacetime publish "${PUBLISH_ARGS[@]}"
popd || exit 1

message "Generating client bindings from $STDB_PROJECT_PATH/$STDB_WASM_PROJECT_RELATIVE_PATH to $STDB_TYPESCRIPT_OUTPUT_PATH"
spacetime generate --lang typescript --out-dir $STDB_TYPESCRIPT_OUTPUT_PATH --bin-path "$STDB_PROJECT_PATH/$STDB_WASM_PROJECT_RELATIVE_PATH"

[Billzabob]

Running spacetime start fixed it for me. I now see that it mentions that in Getting Started but it should also probably be mentioned in the Server Module Quickstart that I was going off of.

[AbhishekDas2000]

Thanks @puttehi . Running spacetime start fixed this. I agree with @Billzabob that the docs need to be updated