Disconnect with intent

[onx2]

Description of Changes

Adds a new DisconnectIntent API to the Rust SDK. Consumers can use on_disconnect_with_intent to distinguish client-requested disconnects, lost connections, and SDK errors. The existing on_disconnect API remains unchanged for compatibility.

Use case

Automatic reconnect should apply only to unexpected disconnects, and application-requested disconnects are distinct. For example, when a game player logs out or switches accounts, the client intentionally calls disconnect(). If the reconnect system treats that event like a network failure, it may reconnect with the cached credentials, restore subscriptions, and make the player appear online again—or reconnect to the wrong account or database (depending on user's implementation).

Exposing whether a disconnect was intentional lets integrations such as bevy_stdb reconnect after network/server failures while remaining disconnected after explicit application shutdown or logout using internal SDK semantics.

API and ABI breaking changes

This is additive and does not break the existing API or ABI, but I think in v3 the on_disconnect should be replaced by this version.

Expected complexity level and risk

1/5

This adds disconnect intent information without changing existing behavior for current consumers.

Testing

• cargo check -p spacetimedb-sdk
• cargo test -p spacetimedb-sdk --lib
• Unit tests for requested, lost, and errored disconnects.
• Verify the new callback with a live server disconnect and reconnect.

[onx2]

Making this a function might be a little overkill 🤷🏻

[bfops]

Hey @onx2, thanks for opening a PR. Just a heads up that we're currently in the process of reworking the client connection logic; it will probably land sometime in September. I think we'll want to re-evaluate something like this after that.

That said, we would likely want to implement this for all SDKs if we're going to move forward with it.

[onx2]

Hey @onx2, thanks for opening a PR. Just a heads up that we're currently in the process of reworking the client connection logic; it will probably land sometime in September. I think we'll want to re-evaluate something like this after that.

That said, we would likely want to implement this for all SDKs if we're going to move forward with it.

NP, thanks for the quick turnaround. Let me know when that time comes, I'd love to be a fly on the wall and am happy to implement for all SDKs when a final approach is decided.