# Description of Changes
Major documentation overhaul focusing on tables, column types, and
indexes.
**Quickstart Guides:**
- Updated React, TypeScript, Rust, and C# quickstarts with table/reducer
examples
- Fixed CLI syntax (positional `--database` argument)
- Improved template consistency across languages
**Tables Documentation:**
- Added "Why Tables" section explaining table-oriented design philosophy
(tables as fundamental unit, system tables, data-oriented design
principles)
- Added "Physical and Logical Independence" section explaining how
subscription queries use the relational model independently of physical
storage
- Added brief sections linking to related pages (Visibility,
Constraints, Schedule Tables)
- Renamed "Scheduled Tables" to "Schedule Tables" throughout (tables
store schedules; reducers are scheduled)
**Column Types:**
- Split into dedicated page with unified type reference table
- Added "Representing Collections" section (Vec/Array vs table
tradeoffs)
- Added "Binary Data and Files" section for Vec<u8> storage patterns
- Added "Type Performance" section (smaller types, fixed-size types,
column ordering for alignment)
- Added complete example struct demonstrating all type categories
- Renamed "Structured" category to "Composite"
**Indexes:**
- Complete rewrite with textbook-style documentation
- Added "When to Use Indexes" guidance
- Documented single-column and multi-column index syntax (field-level
and table-level)
- Comprehensive range query examples with correct TypeScript `Range`
class syntax
- Explained multi-column index prefix matching semantics
- Added index-accelerated deletion examples
- Included index design guidelines
**Styling:**
- Added CSS for table border radius and row separators
- Created Check component for green checkmarks in tables
# API and ABI breaking changes
None. Documentation only.
# Expected complexity level and risk
1 - Documentation changes only, no code changes.
# Testing
- [ ] Verify docs build without errors
- [ ] Review rendered pages for formatting issues
- [ ] Confirm code examples are syntactically correct
---------
Signed-off-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com>
Signed-off-by: John Detter <4099508+jdetter@users.noreply.github.com>
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com>
# Description of Changes
I believe that local users do not have API tokens for OpenAI, so the
existing hint was not helpful. Apparently the correct path is to post
`/update-llm-benchmark` on the PR and let the CI take care of it.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
None
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
Add `impl MemoryUsage for TxState` and all the types below.
Extracted from https://github.com/clockworklabs/SpacetimeDB/pull/3831 to
reduce the diff to ease figuring out why its not helping perf.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
This is the second step to make in-memory-only databases not touch the
disk at all.
While at it, also make it so file-backed module logs are streamed in
constant memory where possible.
Depends-on: #3912
# Expected complexity level and risk
2
# Testing
Added some unit-level tests.
---------
Signed-off-by: Kim Altintop <kim@eagain.io>
Co-authored-by: Phoebe Goldman <phoebe@clockworklabs.io>
Notifications were sent shortly before dropping the actor (and thus, the
lockfile), which could cause the `close` future to return while the lock
is still held.
This can lead to a race if the database is re-opened immediately, such
as in `TestDB::reopen()`, causing test flakes.
# Expected complexity level and risk
1
# Testing
Should result in "Database is already opened" test flakes to go away.
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
Fix LLM benachmarks in rust since they used Result instead of ResultRow
in the request to the LLM making it always fail.
1. see the answer's file there it is ResultRow.
2. Result is a keyword so it will always fail
# API and ABI breaking changes
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
# Expected complexity level and risk
<!--
How complicated do you think these changes are? Grade on a scale from 1
to 5,
where 1 is a trivial change, and 5 is a deep-reaching and complex
change.
This complexity rating applies not only to the complexity apparent in
the diff,
but also to its interactions with existing and future code.
If you answered more than a 2, explain what is complex about the PR,
and what other components it interacts with in potentially concerning
ways. -->
1
# Testing
<!-- Describe any testing you've done, and any testing you'd like your
reviewers to do,
so that you're confident that all the changes work as expected! -->
Run /update-llm-benchmark to see if more passes.
---------
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
In `eval_updates_sequential`, if here are no queries, don't eval updates
at all.
Found via flamegraph. Makes `eval_updates_sequential` take 3.3% of
`commit_and_broadcast_event` instead of 8%.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Description of Changes
Just adds public accessors for some existing internal functionality, to
enable a change in another repo. Review starting from there.
# API and ABI breaking changes
These crates are marked unstable.
# Expected complexity level and risk
0.5
# Testing
See other PR.
---------
Co-authored-by: Kim Altintop <kim@eagain.io>
# Description of Changes
Update the path of dirName to match the correct path.
# API and ABI breaking changes
None.
# Expected complexity level and risk
0.0001
# Testing
Tested locally by running Docusaurus
# Description of Changes
Anther knob for benchmarking only without job core pinning but keeping
other core pinning (tokio background, rayon, etc.).
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
No semantic changes.
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
- Small fix for checking to see if a port is available on some given
interface.
updated:
The original implementation here used `bind` to try to discover if a
port is currently in use. This isn't reliable due to platform
differences - especially on windows where it's apparently acceptable to
have a service running on both `0.0.0.0:3000` and `127.0.0.1:3000`. This
would cause bind to return successfully when we wanted it to fail. Also:
binding on an ipv6 interface when a machine doesn't have ipv6 enabled
caused random errors and it was too unreliable to be useful.
This new implementation uses `get_socket_info` which returns info on all
sockets in use on the system. We can then look through this list to find
services which conflict with our requested port.
updated 1/14:
This PR now includes a fix for flaky CLI tests. Originally we were using
`find_free_port` to pick a random free port, but that was causing a race
condition which resulted in test flakes. This PR fixes this issue by
using `127.0.0.1:0` as the listen addr so the kernel will automatically
pick a free port for us.
# API and ABI breaking changes
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
None
# Expected complexity level and risk
<!--
How complicated do you think these changes are? Grade on a scale from 1
to 5,
where 1 is a trivial change, and 5 is a deep-reaching and complex
change.
This complexity rating applies not only to the complexity apparent in
the diff,
but also to its interactions with existing and future code.
If you answered more than a 2, explain what is complex about the PR,
and what other components it interacts with in potentially concerning
ways. -->
1 - this is a pretty isolated check, unlikely to introduce larger
issues.
# Testing
<!-- Describe any testing you've done, and any testing you'd like your
reviewers to do,
so that you're confident that all the changes work as expected! -->
I tested on macos, windows and linux:
```
ALLOW
docusaurus is already running on 127.0.0.1:3000
SpacetimeDB then tries to start on 192.168.1.10:3000
ALLOW
docusaurus is already running on ::1:3000
SpacetimeDB then tries to start on 192.168.1.10:3000
DENY
docusaurus is already running on ::1:3000
SpacetimeDB then tries to start on 127.0.0.1:3000
DENY
docusaurus is already running on 0:0:0:0:0:0:0:0:3000
SpacetimeDB then tries to start on 0.0.0.0:3000
DENY
docusaurus is already running on 0:0:0:0:0:0:0:0:3000
SpacetimeDB then tries to start on 127.0.0.1:3000
DENY
docusaurus is already running on 0:0:0:0:0:0:0:0:3000
SpacetimeDB then tries to start on 192.168.1.10:3000
DENY
docusaurus is already running on 127.0.0.1:3000
SpacetimeDB then tries to start on 0:0:0:0:0:0:0:0:3000
DENY
docusaurus is already running on 192.168.1.10:3000
SpacetimeDB then tries to start on 0:0:0:0:0:0:0:0:3000
```
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
- Version bump to `v1.11.3` for just the CLI and rust
# API and ABI breaking changes
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
None
# Expected complexity level and risk
1
<!--
How complicated do you think these changes are? Grade on a scale from 1
to 5,
where 1 is a trivial change, and 5 is a deep-reaching and complex
change.
This complexity rating applies not only to the complexity apparent in
the diff,
but also to its interactions with existing and future code.
If you answered more than a 2, explain what is complex about the PR,
and what other components it interacts with in potentially concerning
ways. -->
# Testing
<!-- Describe any testing you've done, and any testing you'd like your
reviewers to do,
so that you're confident that all the changes work as expected! -->
- [x] CLI version has been updated
- [x] Version + date in the license file has been updated
# Description of Changes
This PR adds a regression test covering nullable reference-type view
returns in C# modules (e.g. Account? where Account is a class), as
reported in
[#3962](https://github.com/clockworklabs/SpacetimeDB/issues/3962).
```csharp
public static Account? MyAccount(ViewContext ctx)
```
* Updated the C# regression-test server module to include a
reference-type table and views that exercise the RefOption path:
* A new public reference-type table row:
```csharp
[SpacetimeDB.Table(Name = "account", Public = true)]
public partial class Account { ... }
```
* A public at-most-one view that returns a nullable reference type
(Account?) via Find(...):
```csharp
[SpacetimeDB.View(Name = "my_account", Public = true)]
public static Account? MyAccount(ViewContext ctx)
{
return ctx.Db.account.Identity.Find(ctx.Sender) as Account;
}
```
* A second public view that returns null to ensure the “empty result”
case is exercised:
```csharp
[SpacetimeDB.View(Name = "my_account_missing", Public = true)]
public static Account? MyAccountMissing(ViewContext ctx) => null;
```
* Updated ClientConnected to ensure an Account row exists for the
connecting identity so the “one row” case is deterministic.
* Updated the C# regression-test client to:
* Subscribe to the new views:
* `SELECT * FROM my_account`
* `SELECT * FROM my_account_missing`
* Assert correct semantics for nullable reference-type view returns:
* MyAccount.Count == 1
* MyAccountMissing.Count == 0
* Updated the regression-test server project to use local C#
runtime/codegen project references so the regression module exercises
the in-repo generator/runtime behavior (instead of the published
SpacetimeDB.Runtime package).
# API and ABI breaking changes
None.
* No changes to public module schema/wire format semantics beyond adding
regression-test-only tables/views.
* No behavior changes outside the C# regression test module + harness.
# Expected complexity level and risk
2 - Low
* Changes are isolated to regression tests and project wiring.
* The scenario specifically guards the nullable reference-type
“Option-like view return” path against regressions.
# Testing
<!-- Describe any testing you've done, and any testing you'd like your
reviewers to do,
so that you're confident that all the changes work as expected! -->
- [X] Ran C# regression tests with no failures in new View tests
Signed-off-by: Ryan <r.ekhoff@clockworklabs.io>
# Description of Changes
- Updated Unreal codegen to work with ::Result to match how ::Option
works to create a new struct for each type pair identified
- Added new integration tests to confirm Ok state for all new types
added to sdk-tests
- Added new UE_SPACETIMEDB_RESULT macro to capture de/serialization for
the new structs
# API and ABI breaking changes
N/A
# Expected complexity level and risk
2 - Added new type generated from Result which creates new structs for
each one identified
# Testing
- [x] Updated the integration tests to include the new Result types
---------
Co-authored-by: Mario Alejandro Montoya Cortes <mamcx@elmalabarista.com>
# Description of Changes
This PR fixes a C# SDK regression where using `Bound` in index filters
could trigger an ambiguous reference compiler error for Local after
upgrading to `v1.11.2`, as reported in
[#3995](https://github.com/clockworklabs/SpacetimeDB/issues/3995).
It also fixes a related warning-spam regression (`CS0436`) where user
projects could see `Local` type conflicts between generated module code
and the `SpacetimeDB.Runtime` assembly.
* Introduced a public `SpacetimeDB.Bound` type so users no longer need
to import `SpacetimeDB.Internal` to use bounds in index filters.
* Kept `SpacetimeDB.Internal.Bound` for compatibility, but added
implicit conversions between `SpacetimeDB.Internal.Bound` and
`SpacetimeDB.Bound`.
* Updated the C# code generator to emit fully-qualified
`global::SpacetimeDB.Bound` in generated index filter signatures,
avoiding `SpacetimeDB.Internal` in public-facing APIs and preventing
name collisions (e.g., `Local`).
* Updated internal runtime bounds helpers (`BTreeIndexBounds<...>`) to
explicitly use `SpacetimeDB.Bound` when constructing range-scan
arguments.
* Updated Codegen snapshot fixtures to match the new generated output
(type name + formatting).
* Fixed codegen output for `ITableView` `static abstract` member
implementations to generate `public static` methods (required for the
generated code to compile).
It also fixes a related warning-spam regression (CS0436) where user
projects could see Local type conflicts between generated module code
and the SpacetimeDB.Runtime assembly.
Additional fix (related to the `Local` reports):
* Removed the runtime assembly’s ownership of `SpacetimeDB.Local`
(introduced more recently than the generated module `Local`) to prevent
`CS0436` duplicate-type warnings. Basically, the runtime’s concrete
`Local`/`ProcedureTxContext` helpers were renamed and made internal so
the code generator remains the sole owner of module-level
`SpacetimeDB.Local`.
Regression coverage:
* Added generator regression assertions to ensure generated code does
not reference `global::SpacetimeDB.Internal.Bound<...>` and does
reference `global::SpacetimeDB.Bound<...>`.
* Added a runtime API regression assertion that `SpacetimeDB.Bound`
exists and is public in the runtime reference.
* Added a regression assertion that `SpacetimeDB.Runtime` does not
define codegen-owned types (e.g. `SpacetimeDB.Local`,
`ProcedureContext`, etc.) to prevent future `CS0436` conflicts.
* Added a “simulated downstream user file” compile check ensuring no
`CS0436` diagnostics occur when user code references
`SpacetimeDB.Local`.
# API and ABI breaking changes
None.
* No schema or wire-format changes.
* The changes are limited to C# type exposure / naming and codegen
output.
* `SpacetimeDB.Internal.Bound` remains usable via implicit conversions
(backwards compatible for existing code).
# Expected complexity level and risk
2 - Low
* Changes are isolated to C# runtime type exposure, codegen type
references, and snapshot updates.
* No runtime behavior changes to index scan encoding/decoding; only
avoids requiring SpacetimeDB.Internal in user code.
# Testing
- [X] Ran:`dotnet test
crates/bindings-csharp/Codegen.Tests/Codegen.Tests.csproj`
- [X] Ran regression tests locally.
This also has a few minor changes to fix build errors for the
`test-app`.
# Description of Changes
Updates the typescript-test CI job to build some packages that weren't
being built before.
This also updates the root-level `pnpm generate/format/lint/build`
commands to also apply to templates.
# Expected complexity level and risk
1
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
We've received a number of community pull requests which add `impl
FilterableValue` for new column types, without implementing the features
which `FilterableValue` is intended to describe. This PR extends the doc
comments on `FilterableValue` to explicitly write what the requirements
are to add a new implementation.
# API and ABI breaking changes
N/a
# Expected complexity level and risk
N/a
# Testing
N/a
# Description of Changes
Despecializes direct indices for `u64` keys that have too large values
and convert them into a B-Tree index instead.
Otherwise, we are exposed to OOM aborts.
Also hardens typed index tests to cover more combinations.
This is how the bug was caught.
Some index code is also simplified.
# API and ABI breaking changes
None
# Expected complexity level and risk
2?
# Testing
Proptests were generalized to catch the bug and to then verify that it
was fixed.
# Description of Changes
- Add an "Authentication" section under "Core concepts"
- Add an introduction about how and explanations about common topics
- Move claims usage out of SpacetimeAuth docs
- Update SpacetimeAuth docs to the new version of the dashboard
# API and ABI breaking changes
None.
# Expected complexity level and risk
2
# Testing
Tested locally using Docusaurus
---------
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
# Description of Changes
Fixes https://github.com/clockworklabs/SpacetimeDB/issues/1122.
Adds hash indices and exposes them through `#[index(hash)]` for Rust
modules,
with support for typescript and C# to come in follow ups.
On the client/sdk side, for now, any index is backed via a BTree/native
index as it is the most general.
A hash index may only be queried through point scan and never ranged
scans.
Attempting a ranged scan results in an error, with the mechanism
implemented in the previous PR
(https://github.com/clockworklabs/SpacetimeDB/pull/3974).
# API and ABI breaking changes
None
# Expected complexity level and risk
2?
# Testing
A test for ensuring that hash indices cannot be used for range scans is
added.
Tests exercising hash indices will come in the next PR.
# Description of Changes
Augmented the concurrency group to not have unrelated comments cancel
the `/update-llm-benchmark` command.
# API and ABI breaking changes
CI only
# Expected complexity level and risk
1
# Testing
I think this can only be tested once merged? Comments on this PR still
seem to use the old workflow.
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
Implements the `Nameable` interface for the generated uuid client
bindings.
# API and ABI breaking changes
None.
# Expected complexity level and risk
1. Only additive changes pretty much copy pasted from the other types
where it was already implemented.
# Testing
- [x] Before it didnt work in my project now it works
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
When doing a ranged seek on a non-ranged index (none such exist yet, but
will be added in a follow up), return an (ABI) error.
Also:
- Use point scans in query execution (`IxScan(Delta)Eq`).
- Refactor table index code with macro `same_for_all_types`.
# API and ABI breaking changes
None
# Expected complexity level and risk
2?
# Testing
Testing the error handling will be possible once hash indices are added
(follow up PR).
# Description of Changes
- Made spacetime dev <database> a positional argument and deprecated
--database
- Fixed double connection in React SDK
- Added a more descriptive error message to unresolved table name.
# API and ABI breaking changes
Deprecates `--database`. Still works, but it prints with a warning.
# Expected complexity level and risk
2
# Testing
- [x] I have tested that the double render fix works in React
---------
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
## Summary
- Fixes critical memory leak in Unreal C++ generated code where
`NewObject<UReducer>()` is called for every reducer event but never
cleaned up
- At 30Hz server tick rate (common for game servers), this creates ~30
orphaned UObjects per second, causing continuous memory growth
- Solution: Pass stack-allocated `FArgs` struct directly via new
`InvokeWithArgs()` method instead of allocating UObjects
## Problem
The generated `ReducerEvent` handler in `SpacetimeDBClient.g.cpp`
creates a new UObject for every reducer event:
```cpp
FArgs Args = ReducerEvent.Reducer.GetAs...();
UReducer* Reducer = NewObject<UReducer>(); // LEAK - never cleaned up!
Reducer->Param = Args.Param;
Reducers->Invoke...(Context, Reducer);
```
Unreal's garbage collector cannot keep up at high frequencies. Attempts
to fix with `MarkAsGarbage()`, `ConditionalBeginDestroy()`, and
transient package flags all failed because GC timing is unpredictable.
## Solution
Eliminate UObject allocation entirely by passing `FArgs` directly:
```cpp
FArgs Args = ReducerEvent.Reducer.GetAs...();
Reducers->Invoke...WithArgs(Context, Args); // Zero allocation!
```
The original `Invoke()` methods that take `UReducer*` are preserved for
backwards compatibility.
## Changes
1. **Header generation** (~line 2515): Add `InvokeWithArgs()` method
declaration
2. **ReducerEvent handler** (~line 3194): Call `InvokeWithArgs()`
instead of creating UObject
3. **Implementation** (~line 3703): Add `InvokeWithArgs()` that extracts
params from `FArgs` struct
## Test Plan
- [x] Verified with 30Hz `TickGameScheduled` reducer - UObject count
remains stable
- [x] Memory growth eliminated (was ~1000 UObjects per 14 seconds)
- [x] Backwards compatibility preserved - existing `Invoke()` methods
still work
## Before/After
**Before**: `OBJS` count in Unreal stats continuously increasing, memory
growing unbounded
**After**: `UObjDelta=0` - no UObject growth from reducer events
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Co-authored-by: Jason Larabie <jason@clockworklabs.io>
# Description of Changes
Updated the handler from OnRawMessage to OnBinaryMessage as OnRawMessage
seems to have a bug that won't report the BytesRemaining for incomplete
messages. OnBinaryMessage properly returns a bool flag like how the C#
implementation works.
# API and ABI breaking changes
N/A
# Expected complexity level and risk
2 - Underlying framework change on how messages are handled
# Testing
Blackholio was no longer working and is back in working order; however
Unreal test framework has been broken due to the work on Result<> as the
companion PR has not been merged.
- [x] Rebuilt and ran Unreal Blackholio
It is possible that, under pathological conditions, a database has a
huge transaction backlog, or that there is some bug that prevents
progress on draining this backlog upon shutdown.
In order to avoid piling up `exit_module_host` tasks (which we would not
notice), impose a timeout to be specified after which `exit_module_host`
will drop resources without waiting for the shutdown to complete
gracefully.
# Description of Changes
Adds a feature `no-core-pinning` that disables core pinning.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
Covered by existing tests.
# Description of Changes
Provides common traits `Index` and `RangedIndex` that all (current)
variants in `TypedIndex` adhere to.
This is then used to simplify `TypedIndex` by merging common code,
with more simplifications to come later.
The responsibility of tracking statistics is also moved into each index
type, as some can exploit their properties to provide some statistics
for free, rather than storing statistics in fields.
# API and ABI breaking changes
None
# Expected complexity level and risk
2?
# Testing
This is mostly code motion, so it is covered by existing tests.
Further test improvements will come in a follow up PR.
# Description of Changes
Typo fix.
# API and ABI breaking changes
None.
# Expected complexity level and risk
### 0:
Comment changes only.
# Testing
- [x] Eyeballing it
# Description of Changes
Fixes the deadlock in procedures due to holding tx lock across `async`
abis.
More info can be found here -
https://discordapp.com/channels/931210784011321394/1011381307965722774/1458432377574658060.
This patch converts following procedure abis from `async` to sync, which
may seem problematic but it's not as we already hold tx locks in
reducers while blocking the worker thread.
```rust
"spacetime_10.3"::procedure_start_mut_tx,
"spacetime_10.3"::procedure_commit_mut_tx,
"spacetime_10.3"::procedure_abort_mut_tx,
```
# API and ABI breaking changes:
I am surprised that this does not turned out to be ABI breaking change.
Maybe because from wasm side, async abis were always treated as
synchoronous.
# Expected complexity level and risk
2, diff is straightforward but it can have hidden implications.
# Testing
I want someone else to also do the similar testing as mine. Just in
case, I missed something and that appeared it to work.
I did the backward compatible testing as following:
1. I published following module on master branch:
```rust
use spacetimedb::{ProcedureContext, Table};
#[spacetimedb::table(name = my_table)]
struct MyTable {
a: u32,
b: u8,
}
#[spacetimedb::procedure]
fn insert_a_value(ctx: &mut ProcedureContext, a: u32, b: u8) {
ctx.with_tx(|ctx| {
ctx.db.my_table().insert(MyTable { a, b });
});
}
```
2. Called a procedure to insert some values: `spacetime call quick
insert_a_value 1 2`
3. Switched to my branch, re-compiled and restarted the server.
4. Called a procedure again with different values, verfied both old and
new values are present.
---------
Signed-off-by: Shubham Mishra <shivam828787@gmail.com>
Co-authored-by: Phoebe Goldman <phoebe@clockworklabs.io>
# Description of Changes
One of the TypeScript UUID tests took several seconds to run, and would
sometimes time out in CI. This PR decreases the number of iterations so
that it runs comfortably.
We do not think that this will materially impact the correctness of the
test.
# API and ABI breaking changes
None. Test only.
# Expected complexity level and risk
1
# Testing
- [x] The test now runs in ~500ms on my machine, instead of ~4s
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
This PR does several small things:
1. It removes the explicit `h1` tags on every page, and either uses the
side bar title directly, or puts it in the frontmatter
2. It merges what are currently called quickstarts into a single Chat
App Tutorial
3. It creates new quickstarts which just use `spacetime dev --template`
to get you up and running quickly
4. It adds a "The Zen of SpacetimeDB" page much like the Zen of Python
which goes over the 5 key principles of SpacetimeDB
5. It reorders all Tabs groups so that the ordering is `TypeScript`,
`C#`, `Rust`, `Unreal`, `C++`, `Blueprints` (order of decreasing
popularity).
6. It improves the sidebar navigation by having categories act as
overview pages, and also fixes the breadcrumbs
7. It fixes various small typos and issues
8. Closes#3610 and adds cursor rules files generally
9. It fixes general styling on the docs page by bring it inline with the
UI design:
Old:
<img width="1678" height="958" alt="image"
src="https://github.com/user-attachments/assets/f36efee6-b81a-4463-a179-da68b3a7152e"
/>
New:
<img width="1678" height="957" alt="image"
src="https://github.com/user-attachments/assets/f430f77d-0663-47f2-9727-45cbfe10e4c7"
/>
https://github.com/user-attachments/assets/adc5a78a-ada8-45b5-8078-a45cb81477a3
# API and ABI breaking changes
This PR does NOT change any old links. It does add new pages though.
# Expected complexity level and risk
3 - it's a large change. I manually tested the TypeScript Chat App
Tutorial but I have not gone through the Rust and C# quickstarts.
However, we have testing on the quickstarts and this is text only so can
be carefully reviewed.
# Testing
<!-- Describe any testing you've done, and any testing you'd like your
reviewers to do,
so that you're confident that all the changes work as expected! -->
- [x] Ran through each step of the Chat App TypeScript tutorial to
ensure it is working
- [x] Ran and tested the styles and the functionality of the side bar
---------
Signed-off-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com>
Co-authored-by: spacetimedb-bot <spacetimedb-bot@users.noreply.github.com>
Co-authored-by: clockworklabs-bot <clockworklabs-bot@users.noreply.github.com>
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
# Description of Changes
Updated the link to target SpacetimeDB repository instead of archived
blackholio repository.
Update the repository structure in the README.md to match the current
one (also sort it alphabetically).
# API and ABI breaking changes
NA
# Expected complexity level and risk
1
# Testing
Visit https://spacetimedb.com/docs/unreal/. this link is already used a
bit below for the text "Blackhol.io"
---------
Signed-off-by: homersimpsons <guillaume.alabre@gmail.com>
Signed-off-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
## Summary
UE5 strict mode requires all UPROPERTY fields to be explicitly
initialized, otherwise the engine logs "property not initialized
properly" errors at startup. This PR ensures generated Unreal C++ code
properly initializes all UPROPERTY fields.
### Changes
- Modified `cpp_ty_init_fmt_impl` to accept `module` parameter for enum
type resolution
- Added initialization for enum types (PlainEnum) using the first
variant as default value
- Updated all call sites in reducer/procedure/struct generation to pass
the module
### Before
```cpp
UPROPERTY(BlueprintReadWrite, Category="SpacetimeDB")
EMyEnumType SomeEnumField; // ERROR: property not initialized properly
```
### After
```cpp
UPROPERTY(BlueprintReadWrite, Category="SpacetimeDB")
EMyEnumType SomeEnumField = EMyEnumType::FirstVariant; // OK
```
### Affected generated code
- Reducer args structs (`FXxxReducerArgs`)
- Reducer classes (`UXxxReducer`)
- Procedure args structs (`FXxxProcedureArgs`)
- Product type structs (`FXxxType`)
## Test plan
- [x] Build codegen crate successfully
- [x] Generate bindings for a project with enum types
- [x] Verify generated code has proper initializers
- [x] Build Unreal project without "property not initialized properly"
errors
---
Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Co-authored-by: Jason Larabie <jason@clockworklabs.io>
# Description of Changes
Make the GH username for this job correspond to an actual GH user, so we
can have it sign our CLA.
# API and ABI breaking changes
CI only
# Expected complexity level and risk
1
# Testing
I think we could test this by having clockworklabs-bot create an
external PR, if we think that's worth it. Alternatively we could merge
and test in prod.
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
The syntax is not supported like shows and must be included in the
`table` macro.
<!-- Please describe your change, mention any related tickets, and so on
here. -->
# API and ABI breaking changes
None.
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
# Expected complexity level and risk
0 No runtime change
<!--
How complicated do you think these changes are? Grade on a scale from 1
to 5,
where 1 is a trivial change, and 5 is a deep-reaching and complex
change.
This complexity rating applies not only to the complexity apparent in
the diff,
but also to its interactions with existing and future code.
If you answered more than a 2, explain what is complex about the PR,
and what other components it interacts with in potentially concerning
ways. -->
# Testing
<!-- Describe any testing you've done, and any testing you'd like your
reviewers to do,
so that you're confident that all the changes work as expected! -->
- [x] Code compiles now.
---------
Signed-off-by: Kilian Strunz <93079615+kistz@users.noreply.github.com>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
This basically fixes a typo in the Read Me file.
# API and ABI breaking changes
No API or ABI changes.
# Expected complexity level and risk
Low risk
# Testing
No executable code changes
Signed-off-by: Dejaime Antônio de Oliveira Neto <contact@dejai.me>
# Description of Changes
This PR fixes a C# SDK/BSATN serialization issue where inserting a
`null` string into a non-nullable `string` column could throw an
`ArgumentNullException` with an unhelpful stack trace, as reported in
[#3960](https://github.com/clockworklabs/SpacetimeDB/issues/3960).
* Updated the C# BSATN runtime to reject `null` for non-nullable
`string` serialization with a clear, actionable error message (guides
users to model nullable strings as `string?` so BSATN encodes an
option).
* Added BSATN runtime unit tests to cover:
* Non-nullable string rejects `null` with an actionable message
* Nullable string (`RefOption<string, BSATN.String>`) round-trips `null`
* Added end-to-end C# regression-test module + client assertions for
#3960:
* Inserting `""` into non-nullable `string` succeeds
* Inserting `null` into non-nullable `string` fails with the expected
message
* Inserting `null` into nullable `string?` succeeds and round-trips as
`null`
# API and ABI breaking changes
None.
* No schema or wire-format changes.
* Behavior change is limited to improving the error surfaced when
attempting to serialize null as a non-nullable BSATN `String`, plus
stricter input validation for `ConnectionId` / `Identity` parsing.
# Expected complexity level and risk
2 - Low
* Changes are isolated to regression test coverage.
* No impact on valid serialization paths; only affects invalid/malformed
inputs and improves diagnostics.
# Testing
- [X] Ran C# regression-tests client and verified new tests pass.
---------
Signed-off-by: Ryan <r.ekhoff@clockworklabs.io>
Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com>
# Description of Changes
This PR fixes Release-only flakiness in C# runtime/property tests by
making `ConnectionId` / `Identity` parsing and related low-level byte
decoding strict about input length.
Previously, length validation relied on `Debug.Assert`, which is
compiled out in Release builds. That meant malformed inputs
(wrong-length spans/strings) could slip through in Release and produce
inconsistent behavior.
Changes:
* Updated `ConnectionId.FromHexString(string hex)` to throw when the
input is not exactly 32 hex characters.
* Updated `Identity.FromHexString(string hex)` to throw when the input
is not exactly 64 hex characters.
* Updated `Util.Read(ReadOnlySpan source, bool littleEndian)` to throw
an `ArgumentException` when `source.Length != sizeof(T)` (instead of
relying on `Debug.Assert`), preventing Release-mode “partial reads” from
incorrectly-sized spans.
# API and ABI breaking changes
None.
* No schema or wire-format changes.
* Behavior change is limited to stricter validation of invalid/malformed
inputs for `ConnectionId` / `Identity` parsing and internal runtime
decoding. Valid inputs are unaffected.
# Expected complexity level and risk
2 - Low
* Changes are isolated to the C# BSATN runtime input validation paths.
* No impact on valid serialization/normal runtime behavior; only affects
invalid inputs and makes behavior consistent between Debug and Release.
# Testing
- [X] Ran C# BSATN runtime tests locally (Debug + Release) and verified
they pass.
# Description of Changes
This PR fixes a C# reducer error-reporting issue where exceptions thrown
in reducers were returned to clients with full stack traces, as reported
in [#3959](https://github.com/clockworklabs/SpacetimeDB/issues/3959).
- Updated the C# reducer host-call error serialization to return only
`Exception.Message` (instead of `Exception.ToString()`), preventing
server-side stack traces from being leaked to clients.
- Added a C# regression-test client assertion to validate reducer
failures do not contain stack traces:
- `exception.Message` matches the thrown message exactly
- the message does not contain newlines or `" at "` stack-trace markers
# API and ABI breaking changes
None.
- No schema or wire-format changes.
- Behavior change is limited to the *contents* of reducer error strings
returned to clients (stack traces removed).
# Expected complexity level and risk
2 - Low
- Change is isolated to C# reducer error formatting plus a regression
assertion.
- Removes unintended information exposure without affecting reducer
success paths.
# Testing
- [X] Ran C# regression-tests client; verified reducer error message is
preserved and stack trace is not present.
## Summary
This fixes a regression introduced in commit afe169ac4 ("Fix the issues
with scheduling procedures #3816", Dec 5, 2025) where scheduled reducers
stopped recording their `ReducerContext` to the commitlog.
**Impact:**
- No `inputs` section was written to the commitlog for scheduled
reducers
- The reducer's name, caller, timestamp, and arguments were not
persisted
## Root Cause
The old code in `module_host.rs::call_scheduled_reducer_inner` patched
`tx.ctx` with the `ReducerContext`:
```rust
tx.ctx = ExecutionContext::with_workload(
tx.ctx.database_identity(),
Workload::Reducer(ReducerContext { ... }),
);
```
This was removed when the logic moved to `scheduler.rs`. The new code in
`call_reducer_with_tx` only applies the `ReducerContext` when `tx` is
`None` — since the scheduler passes `Some(tx)`, the context was never
applied.
## Fix
Restore the `tx.ctx` patching in `scheduler.rs` before calling
`call_reducer_with_tx`.
## Test Plan
- [ ] Existing tests pass
Co-authored-by: Phoebe Goldman <phoebe@clockworklabs.io>
# Description of Changes
We would like to move all of the templates to a central directory
# API and ABI breaking changes
None
# Expected complexity level and risk
2
# Testing
---------
Co-authored-by: spacetimedb-bot <spacetimedb-bot@users.noreply.github.com>
Tyler Cloutier