# Description of Changes
Removes `arg_id` from read sets, and also moves view lifecycle
management from `st_view_sub` into the committed state. Trying to move
away from system tables and persistent state in general for views since
this has been the source of many issues.
# API and ABI breaking changes
None
# Expected complexity level and risk
2
# Testing
Existing coverage.
Re-enable the Nix flake on aarch64-darwin.
PR #3422 added the flake but bailed out on Darwin pending a fix for
"could not find native static library `rusty_v8`". With v8 now on
145.0.0 (PR #4073) the build itself works on aarch64-darwin, so this
removes the `builtins.abort` guard and fills in the real sha256 for the
v145.0.0 rusty_v8 archive on aarch64-darwin.
The underlying bug — v8's build.rs writing `librusty_v8.a` outside the
locations cargo and crane treat as authoritative — already has a known
workaround in PR #3921, but that fix only lives in
`.github/workflows/ci.yml` and so does not protect the Nix build. This
ports the equivalent guard into the flake as a `preBuild` on
`commonArgs`: if the v8 build directory exists but `librusty_v8.a` is
missing, clean and rebuild just the v8 crate. With current
nixpkgs/crane the file does in fact survive the `buildDepsOnly` →
`buildPackage` handoff on aarch64-darwin, so the guard no-ops on the
happy path; it is defence-in-depth for the next time crane or nixpkgs
shifts.
x86_64-darwin and aarch64-linux still use placeholder hashes; users on
those platforms will continue to hit the existing fail-then-paste-hash
loop documented in `librusty_v8.nix`.
# API and ABI breaking changes
None. Build-system only, no runtime change.
# Expected complexity level and risk
1.
# Testing
- [x] `nix flake check --no-build` passes on aarch64-darwin.
- [x] `nix build .#default` produces working `spacetime`,
`spacetimedb-cli`, and `spacetimedb-standalone` binaries; all three
report `spacetimedb tool version 2.3.0`.
- [x] `nix build .#checks.aarch64-darwin.workspace-fmt` passes.
- [x] `nix develop --command rustc --version` succeeds (the command
originally reported failing before this change).
- [x] Confirmation from a reviewer with x86_64-linux that the change
has not regressed the previously working platform.
Co-authored-by: Phoebe Goldman <phoebe@clockworklabs.io>
## Summary
`XForwardedFor::decode` requires a comma and fails to decode
`X-Forwarded-For: 1.2.3.4`.
Under axum 0.8 this now surfaces as HTTP 400 on every single-hop-proxy
request.
## Fix
Accept comma-separated or single-IP values — take the first entry either
way.
## Reproducer
Any browser going through a proxy that does `.insert("x-forwarded-for",
client_ip)`
(standard single-hop pattern) sees 400 Bad Request on WebSocket
subscribe.
## Version regression
Bug latent since the axum migration in 2023-06 (commit b4dae7475). axum
0.7
silently dropped the decoder error via `Option<TypedHeader<T>>`; axum
0.8
(#2713) promotes it to a 400 rejection.
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
# Description of Changes
An evolution of https://github.com/clockworklabs/SpacetimeDB/pull/4707
where i explored adding a `db_read_only` method to `DbContext`. (hence i
would appreciate your thoughts @gefjon )
This was the wrong appraoch in retrospect because there are still some
annoyances with this.
Furthermore there is really no benefit to adding the associated type
`DbView` and is just making the ergonomics worse.
So here is the new approach which solved all my problems:
Making a trait for every capability which the various contexts are
providing because the Databse is only one of them.
These capabilities are (and pretty much the whole relevant div for this
pr because the impl blocks are trivial) and should be self explanatory:
```rust
pub trait CtxDbRead {
fn db_read_only(&self) -> &LocalReadOnly;
}
pub trait CtxDbWrite: CtxDbRead {
fn db(&self) -> &Local;
}
pub trait CtxWithSender {
fn sender(&self) -> Identity;
}
pub trait CtxWithTimestamp {
fn timestamp(&self) -> Timestamp;
}
pub trait CtxWithHttp {
fn http(&self) -> &HttpClient;
}
```
## Why is this relevant?
Lets look at an example building on the previous pr:
You have abstracted your code in a trait which you can call for every
context e.g. authorization.
Now this does not work because the sender method is not available on
`DbContext`.
```rust
impl<Db: CtxDbRead> Authorization for Db {
fn test(&self,args:Args) {
self.db_read_only().do_i_have_perms().find(self.sender()); //ERROR: no sender method
}
```
Now this is really annoying since you now have to pass additional
parameters to the method.
Instead we can now specific these capabilities in the type system:
```rust
impl<Db: CtxDbRead+CtxWithSender> Authorization for Db {
fn test(&self,args:Args) {
self.db_read_only().do_i_have_perms().find(self.sender()); //WORKS NOW YAY
}
```
Additonally there could be also a `+ CtxWithTimestamp` if you wanted to
for example store a last logged in date or smth (you get the idea)
Now this is far better because `.sender` is available for `ViewContext`
for example so you can authorize with the same method.
## Alternatives/Bikeshedding
I chose the names CtxWith because really the `Contexts` are the common
denominator and not the `Database`.
Thats also the reason why its `CtxDbRead` because you are expressing:
"All context where i get read access to the databse (e.g. everything).
Other names have felt worse.
Also the deprecation can be removed but i think this approach is
strictly superior and i dont think there are currently many people
relying on it.
# API and ABI breaking changes
None. one deprecation for the old `DbContext` but this can also be
removed if desired.
# Expected complexity level and risk
1. Additive change with extremly minimal surface
# Testing
- [x] Works for my project
---------
Signed-off-by: Kilian Strunz <93079615+kistz@users.noreply.github.com>
Co-authored-by: Phoebe Goldman <phoebe@goldman-tribe.org>
## Summary
- Codegen unconditionally emits `.primaryKey()` on all primary key
columns, including enum types
- `SumBuilderImpl` (used for **all** object-form enums via
`__t.enum("Name", { ... })`) only implemented `Defaultable` and
`Nameable` — not `PrimaryKeyable` or `Indexable`
- This causes a runtime `TypeError: SC.primaryKey is not a function`
whenever an enum type is used as a primary key column
## Fix
Add `Indexable` and `PrimaryKeyable` interfaces and their methods to:
- `SumBuilderImpl` (the base class for all enum type builders)
- `SumColumnBuilder` (the column builder returned by `SumBuilderImpl`
methods)
This matches the existing pattern already present in
`SimpleSumBuilderImpl` and `SimpleSumColumnBuilder`.
## Why SumBuilderImpl and not just SimpleSumBuilderImpl?
Codegen always generates object-form enums:
```typescript
export const PlatformModuleType = __t.enum("PlatformModuleType", {
Standard: __t.unit,
Control: __t.unit,
});
```
The runtime dispatch in `type_builders.ts` (line ~3656) routes
object-form enums to `SumBuilder` (backed by `SumBuilderImpl`), never to
`SimpleSumBuilder`. So `SimpleSumBuilderImpl`'s existing
`primaryKey()`/`index()` methods are effectively dead code for codegen
output.
## Test plan
- [x] Verify enum types used as primary keys no longer throw `TypeError:
SC.primaryKey is not a function`
- [ ] Verify existing `SimpleSumBuilderImpl`/`SimpleSumColumnBuilder`
behavior is unchanged (subclass overrides still work)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
# Description of Changes
Instead of baking it into the query plan. The query plan should
parameterize anonymous views just like sender-scoped views. We need this
for the next step which is plan sharing for subscriptions.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
Existing coverage
# Description of Changes
Updates the TypeScript code generator to emit correct `.name()` values
on table fields, and updates the three affected Case Conversion Test
snapshots.
**Problem:** For source identifiers with mixed/PascalCase casing (e.g.,
`Player1Id`), the in-process codegen path used by `cargo test` and
`check-diff.sh` emitted `.name()` calls using the pre-conversion
identifier (`name('Player1Id')`) instead of the canonical database
column name (`name('player_1_id')`). The CLI `spacetime generate` path
was already correct because its `extract-schema` round-trip
canonicalizes names before codegen. The two paths disagreed, causing
`check-diff` CI failures.
**Root cause / Fix:** `write_object_type_builder_fields` in
`crates/codegen/src/typescript.rs` was using the `TypespaceForGenerate`
pre-conversion identifier for `.name()`. It now accepts an optional
`&[ColumnDef]` and emits `column.name` for table fields. The camelCase
accessor key (e.g., `player1Id`) is unchanged; only the underlying
wire/database column name is corrected to snake_case.
The three snapshot files in
`crates/bindings-typescript/case-conversion-test-client/src/module_bindings/`
are updated to match the corrected output.
# API and ABI breaking changes
No API or ABI changes at the Rust crate or C ABI level.
For TypeScript users, this is a bug fix for the in-process generation
path; the CLI path was already correct.
# Expected complexity level and risk
1 - Trivial
# Testing
- [X] Local testing
- Verified the in-process `cargo test -p spacetimedb-sdk --
case_conversion` path on `master` generated incorrect PascalCase
`.name()` values (`name("Player1Id")`, missing `.name()` for
`currentLevel2`/`status3Field`.
- Verified the same in-process path on the PR branch generates correct
snake_case `.name()` values (`name("player_1_id")`,
`name("current_level_2")`, `name("status_3_field")`), matching the
updated snapshots.
- Verified the CLI `spacetime generate --lang typescript` path produces
identical snake_case output on both `master` and the PR branch.
- Created a standalone TypeScript test that confirms the generated
bindings produce SQL with canonical snake_case column names
(`"current_level_2"`, `"player_1_id"`, `"player_ref"`) via the SDK
`toSql()` function.
- [X] CI passing
---------
Signed-off-by: Ryan <r.ekhoff@clockworklabs.io>
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
# Description of Changes
Use `reqwest` for smoketest HTTP API helper calls instead of
hand-writing HTTP over a raw `TcpStream`.
This lets the shared `api_call` helpers work against HTTPS remote
servers as well as local HTTP servers. It also preserves the server URL
protocol when `login_with_token` rewrites a test config.
# API and ABI breaking changes
None.
# Expected complexity level and risk
1. This is a focused smoketest helper change.
# Testing
- [x] `cargo fmt --all --check`
- [x] `git diff --check`
- [x] `cargo check -p spacetimedb-smoketests`
---------
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
# Description of Changes
Adds release tooling under `tools/release` and a manual release workflow
at `.github/workflows/release.yml`.
The release workflow can run the existing release targets for crates.io
packages, the TypeScript SDK, C# SDK, C++ bindings, Docker images, and
the S3 mirror latest-version marker.
# API and ABI breaking changes
None.
# Expected complexity level and risk
2. This moves existing release automation into this repository and
updates paths that previously assumed a nested checkout layout. The main
risk is GitHub Actions wiring and secret availability during a real
release.
# Testing
- [x]
`PATH=/Users/clockworklabs/.rustup/toolchains/1.93.0-aarch64-apple-darwin/bin:$PATH
cargo fmt --all`
- [x]
`PATH=/Users/clockworklabs/.rustup/toolchains/1.93.0-aarch64-apple-darwin/bin:$PATH
cargo check -p spacetimedb-release`
- [x]
`PATH=/Users/clockworklabs/.rustup/toolchains/1.93.0-aarch64-apple-darwin/bin:$PATH
cargo run -q -p spacetimedb-release -- release --help`
- [x] Ruby YAML parse for `.github/workflows/release.yml`
- [x] `git diff --check`
---------
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
# Description of Changes
Adds a Prometheus counter for websocket clients that are disconnected
after the server considers them idle:
-
`spacetime_worker_ws_clients_idle_timed_out_total{database_identity=...}`
The counter is incremented at the existing websocket idle-timeout
disconnect path, next to the `Client ... timed out` log.
# API and ABI breaking changes
None.
# Expected complexity level and risk
1. This is instrumentation-only and does not change websocket behavior.
# Testing
- [x] `rustup run 1.93.0 rustfmt
crates/client-api/src/routes/subscribe.rs
crates/core/src/worker_metrics/mod.rs`
- [x] `git diff --check`
- [x] `LC_ALL=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 LANG=en_US.UTF-8
RUSTC=/Users/clockworklabs/.rustup/toolchains/1.93.0-aarch64-apple-darwin/bin/rustc
rustup run 1.93.0 cargo check -p spacetimedb-client-api -p
spacetimedb-core`
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
Co-authored-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com>
# Description of Changes
#5300 changed the backing table schema of views. While this technically
isn't a breaking change because these tables are ephemeral, the schema
is not ephemeral, so it does require us to update the schema by dropping
and re-adding views once on initial startup.
# API and ABI breaking changes
None
# Expected complexity level and risk
1.5
# Testing
Auto-migration unit tests
# Description of Changes
Add some debugging and retries to this job.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
hard to test without being in prod 🤷
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
LLM benchmark now pulls LLM_BENCHMARK_UPLOAD_URL from inputs instead of
secrets
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
Wait for CI to pass
Signed-off-by: Julien Lavocat <JulienLavocat@users.noreply.github.com>
# Description of Changes
Module launch now exposes a completion handle so callers can wait until
`st_module` is durable before cleaning up controldb bootstrap state.
# API and ABI breaking changes
None
# Expected complexity level and risk
2
# Testing
Tests added in the corresponding private PR that deletes bootstrap state
from the controldb
## Compatibility note
This PR changes the generated TypeScript table/view handles for
snake_case module accessors to the target-language TypeScript accessor
casing, but keeps the old snake_case handles as deprecated aliases.
Generated TS clients now expose the intended TypeScript accessor casing:
- `ctx.db.databaseTree`
- `tables.loggedOutPlayer`
- `tables.myProgress`
The old snake_case handles continue to work and are marked deprecated in
the generated type surface:
- `ctx.db.database_tree` still works as an alias for
`ctx.db.databaseTree`
- `tables.logged_out_player` still works as an alias for
`tables.loggedOutPlayer`
- `tables.my_progress` still works as an alias for `tables.myProgress`
The database canonical names stay unchanged. For example, the generated
TypeScript handle is camelCase, but the table metadata still has `name:
'logged_out_player'`.
## Remaining API breakage risk
This should be non-breaking for normal generated TypeScript client
usage, including:
- direct table access through `conn.db.snake_case`
- callback contexts like `ctx.db.snake_case`
- exported query builders like `tables.snake_case`
- type inference for deprecated aliases
There are still a few edge cases where users may notice an API shape
change:
- Code that enumerates generated table handles with `Object.keys`,
`Object.entries`, `for...in`, or similar will now see both the
target-language handle and the deprecated snake_case alias.
- Code with pathological table/view accessor collisions may not get
every possible alias. The normal case is `logged_out_player` ->
generated handle `loggedOutPlayer` plus deprecated alias
`logged_out_player`. Pathological cases are shapes like:
- `foo_bar` and `fooBar`: both want the generated TypeScript handle
`fooBar`, so generated clients cannot provide two distinct
`tables.fooBar` entries.
- `foo_bar` and some other table/view whose target-language handle is
already `foo_bar`: the deprecated `foo_bar` alias for `foo_bar` ->
`fooBar` would shadow the other generated handle, so the generator skips
that alias.
- Code that compares the exact generated `index.ts` text, emitted
declaration text, or public type names will see new helper/types such as
`DbView`, `Tables`, and the alias metadata.
TypeScript modules themselves are not expected to break from this unless
they consume generated TypeScript client bindings or depend on exact
generated client object keys.
## Terminology
The casing proposal uses **canonical name** for the database/internal
name. That is language-independent. It uses **accessor name** for the
source/module/client-facing identifier that codegen derives
language-specific handles from.
This PR keeps database canonical names unchanged. It changes the
generated TypeScript accessor handles to match TypeScript casing while
retaining the old generated handles as deprecated aliases.
## Why
The TypeScript code generator was using `table.accessor_name` and
`view.accessor_name` directly as object keys in `tablesSchema`. That
preserved the raw module accessor spelling instead of applying the
target-language `Case::Camel` conversion for TypeScript handles. Per the
casing policy, client codegen should use the server accessor name as its
source and apply the target-language conversion.
## What changed
- Convert generated TypeScript table and view handle keys with
`Case::Camel`.
- Generate deprecated snake_case aliases for table/view handles when the
old generated handle differs from the target-language TypeScript handle.
- Keep runtime table metadata and database canonical names unchanged.
- Avoid duplicate runtime table definitions.
- Add a type-only aliased schema so callback contexts infer deprecated
aliases too.
- Add regression coverage for TypeScript-cased handles and deprecated
aliases.
- Update checked-in generated TS bindings and references that change
under this fix.
Generated code in this repo that changes as a result:
- `crates/bindings-typescript/test-app/src/module_bindings/index.ts`
-
`crates/bindings-typescript/test-react-router-app/src/module_bindings/index.ts`
-
`crates/bindings-typescript/test-solid-router/src/module_bindings/index.ts`
-
`crates/bindings-typescript/case-conversion-test-client/src/module_bindings/index.ts`
- `demo/Blackholio/client-ts/src/module_bindings/index.ts`
- `templates/hangman-react-ts/src/module_bindings/index.ts`
- `templates/money-exchange-react-ts/src/module_bindings/index.ts`
- `crates/codegen/tests/snapshots/codegen__codegen_typescript.snap`
I also updated the corresponding client/test references to the generated
TypeScript-cased handles.
## Verification
- `cargo fmt --all --check`
- `cargo test -p spacetimedb-codegen typescript`
- `pnpm --dir crates/bindings-typescript test --
tests/client_query.test.ts tests/db_connection.test.ts`
- `pnpm --dir crates/bindings-typescript exec vitest run
--typecheck.enabled tests/client_query.test.ts
tests/db_connection.test.ts`
- `git diff --check`
The explicit Vitest typecheck command still reports existing global
typecheck errors from unrelated files loaded by the test project,
including missing `spacetimesys@2.x` ambient modules and existing test
type issues, but the touched alias tests report `Type Errors no errors`
and the earlier generated-code `declare override` issue is gone.
---------
Signed-off-by: Ryan <r.ekhoff@clockworklabs.io>
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
Co-authored-by: Ryan <r.ekhoff@clockworklabs.io>
Addresses #5373. Hangs off the reconnect tracking issue #1936.
A SpacetimeDB web app commonly starts a user on an **anonymous**
connection and
then lets them **sign in** (e.g. via Google), at which point you want to
reconnect with the new token. The Svelte binding has no clean way to do
this: it
holds its connection in a **module-level singleton** reused across
remounts (so
even a `{#key}` swap keeps the old token), there's no reconnect path on
the
context value, and a `DbConnection`'s token is immutable after
`build()`. The
only thing that actually works today is `window.location.reload()`,
which throws
away all client state and flickers the UI on every sign-in/sign-out. The
Svelte
binding also lacks the exponential-backoff **auto-reconnect** that React
and
Solid already get from `ConnectionManager`.
This is two focused commits that close both gaps:
# Description of Changes
**1. `Add ConnectionManager.rebuild()` for token-swap reconnects.** The
shared
`ConnectionManager` (used by the React and Solid providers) can hold and
reference-count a connection but has no way to swap a live connection's
builder.
`rebuild(key, builder)` tears down the live connection and builds a
fresh one
from a new builder under the same ref count and listener set, so
framework hooks
(`useTable`, `useReducer`, …) re-bind automatically — swap the token in
the
builder, call `rebuild`, done. The old connection's callbacks are
detached
before it is closed (so its disconnect event can't leak into pool
state), any
deferred release or pending auto-reconnect is cancelled, and the backoff
counter
is reset. This is the `rebuild()` primitive from the open
multi-module-provider
PR #4887 (original design by @Ludv1gL), lifted into a focused change,
adapted to
the current post-#5185 reconnect machinery, and reusing the existing
`#buildManagedConnection` / `#detachCallbacks` helpers rather than that
PR's
`#install` / `#teardown` refactor.
**2. Put the Svelte binding on `ConnectionManager`; add `reconnect()`
for token
swaps.** `createSpacetimeDBProvider` is rebuilt on top of the shared
`ConnectionManager` — the same pool React and Solid already use —
replacing the
bespoke module-level singleton with the manager's reference counting and
deferred cleanup (which absorb HMR / `{#key}` remounts), and getting
exponential-backoff auto-reconnect for free. The context value gains
`reconnect(builder)` (backed by the new `ConnectionManager.rebuild`):
tear down
the current connection and reconnect with a fresh builder carrying a new
token,
no page reload. `useTable` / `useReducer` / `useSpacetimeDB` are
unchanged and
re-bind to the new connection automatically.
# API and ABI breaking changes
Minor, TypeScript-only: `ConnectionState.getConnection` on the Svelte
binding is
no longer generic — it returns `DbConnectionImpl<any> | null`, matching
the
React and Solid bindings. Call sites that wrote
`getConnection<MyConn>()` lose
the type argument; `getConnection()` is unchanged. The provider's return
type
stays `Writable<ConnectionState>`. `ConnectionManager.rebuild` is purely
additive.
# Expected complexity level and risk
2. Low. `rebuild()` is a small method reusing the same build/teardown
helpers as
`retain`/`release` and the auto-reconnect path; the only subtlety is
ordering
(detach-then-close + cancel pending timers so a stale disconnect or
scheduled
auto-reconnect can't race the new connection). The Svelte provider is
now a thin
adapter: it mirrors the manager's store into a Svelte store and wires up
`getConnection` / `reconnect` / `retain` / `release`. The
connection-lifecycle
logic that used to be bespoke here — the singleton, deferred cleanup,
reconnect
— now lives in the well-tested, shared `ConnectionManager` that React
and Solid
already depend on.
# Testing
- [x] Six new unit tests against the real `ConnectionManager` singleton
(`tests/connection_manager_reconnect.test.ts`): builder swap, ref-count
preservation, callback detachment, pending-reconnect cancellation +
backoff
reset, and both `null`-return cases.
- [x] Full vitest suite green; `tsc -p tsconfig.build.json` typechecks;
`build:js` emits the Svelte ESM/CJS + browser bundles cleanly; eslint +
prettier clean.
- [x] Manually smoke-tested end-to-end in a real Svelte app (anonymous →
Google sign-in → signed-in): the token swaps and the board state
survives
with **no page reload**, and sign-out reconnects anonymously the same
way.
- [ ] Reviewer: this package has no Svelte component-test harness today
(the
pre-existing binding had none), so the provider wiring is covered
indirectly
through the `ConnectionManager` unit tests. Worth a call on whether to
add
`@testing-library/svelte` coverage here. Vue has the same singleton
shape and
can follow this pattern as a follow-up.
# Description of Changes
Makes the keynote benchmark job reusable so that it can be invoked and
run in other CI environments.
# API and ABI breaking changes
N/A
# Expected complexity level and risk
2
# Testing
Refactor. Relies on existing coverage.
# Description of Changes
Specifically:
- The number of objects read during replay
- The number of bytes read from disk during replay
- The time spent hashing objects during replay
# API and ABI breaking changes
Not considered breaking, but this patch does add a new label to a
pre-existing metric `spacetime_replay_snapshot_read_time_seconds`.
# Expected complexity level and risk
1.5
# Testing
Updates a pre-existing test
# Description of Changes
Uses `jsonwebtoken v10.4.0` instead. Important changes include:
**1. Token serialization**
Old tokens with `"exp": null` are still accepted, but new no-expiry
tokens now omit `exp` instead of serializing it as `"exp": null`.
**2. OIDC/JWKS validation**
Issuer extraction now uses `jsonwebtoken::dangerous::insecure_decode`
for key discovery only, not validation. And the old `spacetimedb-jwks`
crate required every JWK to have a `kid`, but this patch does not
preserve that limitation.
# API and ABI breaking changes
I don't believe this is considered breaking, but it bears repeating that
new no-expiry tokens now serialize without `exp` instead of `"exp":
null`.
# Expected complexity level and risk
2
# Testing
- [x] Verify a legacy no-expiry token serialized as `"exp": null` still
validates.
- [x] Verify a token with an expired `exp` is still rejected.
- [x] Verify OIDC/JWKS validation works when the JWKS keys omit the
optional `kid` field.
# Description of Changes
We currently have discord notifications when PRs merge into master. We
have two problems:
1. These notifications don't run properly for external PRs (due to
missing secrets)
2. We don't get notifications for other pushes to master
This PR fixes those issues by changing the job to run on any push to
master rather than when a PR is closed.
# API and ABI breaking changes
None. CI only.
# Expected complexity level and risk
1
# Testing
I don't think we can test this without merging into master.
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
Fixes#5407.
A one-column prefix scan on a multi-column btree index — e.g.
`filter(1n)` on a
`[u64, string]` index — panicked at runtime with `TypeError:
serializeTerm is
not a function` inside `serializeRange`.
A bare scalar (or bare `Range`) has no `.length`, so in the multi-column
`filter`/`delete` accessor `range.length === numColumns` was `undefined
=== 2`
(falling into the range-scan branch), and inside `serializeRange`:
- `prefix_elems = range.length - 1` → `NaN` (prefix loop skipped),
- `serializeTerm = indexSerializers[range.length - 1]` →
`indexSerializers[NaN]`
→ `undefined`,
- `serializeTerm(writer, term)` → **`TypeError: serializeTerm is not a
function`**.
A bare scalar is the only *type-valid* way to express a one-column
prefix on a
multi-column index — `filter([1n])` is rejected by the generated types
and
`filter([1n, "x"])` is the full key — so there was previously **no**
working way
to do a one-column prefix scan.
The fix normalizes a non-array `range` to a single-element array at the
top of
the multi-column `filter`/`delete` before reading `.length`, so a bare
scalar or
`Range` is treated as a one-column prefix and takes the range-scan
branch
correctly. The full two-column key path is unchanged and still takes the
point-scan branch.
To regression-test the pure-JS index accessor under vitest,
`makeTableView` is
now exported from `src/server/runtime.ts` (it is **not** re-exported
from any
public entry point), the host-injected `spacetime:sys@*` virtual modules
are
stubbed, and aliased in `vitest.config.ts`.
# API and ABI breaking changes
None. `makeTableView` is newly exported from `src/server/runtime.ts` but
is not
re-exported from any public entry point. The host ABI is unchanged.
# Expected complexity level and risk
1 — a one-line input normalization on each of `filter`/`delete`, plus
test-only
scaffolding. No change to the full-key path or the host syscall
arguments.
# Testing
- [x] `npx vitest run tests/index_prefix_filter.test.ts` — bare scalar,
bare
`Range`, full two-column key, and `delete()` all scan without throwing
(4 passed).
- [x] `npx vitest run` — full suite, 223 passed.
- [x] `tsc -p tsconfig.build.json` and `prettier --check` clean.
- [x] Reviewer: confirm the prefix-scan semantics against a real
datastore
(the unit test uses a stubbed host iterator that yields no rows).
## Summary
Adding `#[unique]` or `#[primary_key]` to an existing column currently
triggers `AutoMigrateError::AddUniqueConstraint`, forcing a full
database clear to apply the schema change. This PR makes it a
non-breaking migration by validating existing data first:
- **If all values are unique**: constraint is added seamlessly
(non-breaking migration)
- **If duplicates exist**: migration fails with a detailed error listing
up to 10 duplicate groups
## Changes
- `auto_migrate.rs`: Replace hard `AddUniqueConstraint` error with
`CheckAddUniqueConstraintValid` precheck + `AddConstraint` migration
step
- `update.rs`: Implement precheck (full table scan, project constrained
columns, count duplicates) and `AddConstraint` step execution
- `relational_db.rs`: Expose `create_constraint()` (counterpart to
existing `drop_constraint()`)
- `traits.rs` / `datastore.rs`: Add `create_constraint_mut_tx` to
`MutTxDatastore` trait
- `mut_tx.rs`: Make `create_constraint` public
- `formatter.rs`: Format the new `AddConstraint` step
## Safety
- **Transaction safety**: Precheck and constraint creation run in the
same `MutTx` — no window for concurrent duplicate inserts
- **Index creation**: `auto_migrate_indexes()` already handles adding
the backing btree index (with `is_unique=true` from the new schema). The
constraint step only adds metadata.
- **Rollback**: If the precheck finds duplicates, the entire migration
aborts before any changes are applied
- **Error quality**: Duplicate error shows table name, column names, and
up to 10 example duplicate values with counts
## Example error output
```
Precheck failed: cannot add unique constraint 'Users_email_key' on table 'Users' column(s) [email]:
3 duplicate group(s) found.
- String("alice@example.com") appears 2 times
- String("bob@example.com") appears 3 times
- String("charlie@example.com") appears 2 times
```
## Test plan
- [x] All 12 `auto_migrate` tests pass
- [x] `cargo check` passes for `spacetimedb-schema` and
`spacetimedb-core`
- [x] Verified the previously-expected `AddUniqueConstraint` error test
is updated
- [x] Manual test: add `#[unique]` to existing column with clean data →
succeeds
- [x] Manual test: add `#[unique]` to existing column with duplicates →
fails with detailed error
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: Mazdak Farrokhzad <twingoow@gmail.com>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
# Description of Changes
In order to be able to suspend databases based on memory usage.
Reports memory usage for wasm linear memory as well as the v8 heap. Also
reports page-level memory for tables.
It does not report memory usage for indexes.
# API and ABI breaking changes
None
# Expected complexity level and risk
1.5
# Testing
Testing added in the private counterpart which handles enforcement of
memory limits.
# Description of Changes
- Fixed an Unreal SDK cache bug with overlapping subscriptions on the
same table called out in
[Discord](<https://discordapp.com/channels/1037340874172014652/1507200761900171405>)
from @defohost
- Merged repeated transaction table updates by table name while
preserving all row-set payloads
- Fixes unique-index `Find(...)` returning empty while `Iter()` still
sees the updated row
- Aligned Unreal transaction update handling with the other SDKs
- Applies one accumulated per-table update per transaction instead of
multiple partial passes
# API and ABI breaking changes
- No intended API or ABI breaking changes to released Unreal SDK
behavior
# Expected complexity level and risk
2 - Small transaction update normalization change, risk is preserving
row multiplicity for overlapping
subscriptions
# Testing
What I've done so far:
- [x] Added and ran a throwaway Unreal repro for overlapping identical
subscriptions on one table
- [x] Ran the full `sdk-unreal-test-harness`
- [x] Tested Unreal Blackholio
### Note 1: this requires a website PR to merge
### Note 2:
I was able to run all workflow smoke tests successfully, including
golden validation and dry-run benchmarks, except for the C# dry-run
benchmark path. C# golden validation passes, but the C# benchmark dry
run still fails intermittently/consistently on the runner despite
several attempts to align its build/publish setup with the known-good
smoketest path.
```
gh workflow run llm-benchmark-periodic.yml `
--repo ClockworkLabs/SpacetimeDB `
--ref bradley/fix-validate-goldens-ci `
-f model_set=explicit `
-f models="openrouter:openai/gpt-5.4-mini" `
-f languages=rust,csharp,typescript `
-f modes=guidelines `
-f tasks=t_000_empty_reducers `
-f dry_run=true
```
# Description of Changes
This updates the LLM benchmark automation and runner plumbing.
- Move periodic LLM benchmark and golden validation workflows from
daily/nightly to weekly Monday UTC runs.
- Add manual workflow inputs for benchmark smoke runs:
- model set: website-managed, local defaults, or explicit models
- languages, modes, categories, tasks
- dry-run mode
- Build the local TypeScript SDK before TypeScript benchmark/golden
validation runs.
- Add support for fetching active/available benchmark models from the
website API via `--model-source remote`.
- Keep explicit `--models ...` working for manual/local overrides.
- Add OpenRouter preflight checks before benchmark execution:
- checks key/account credits when available
- probes the selected model when credit balance cannot be checked
- supports `OPENROUTER_ALLOW_UNCHECKED_CREDITS=1` escape hatch
- supports `OPENROUTER_MIN_CREDITS` / `LLM_MIN_CREDITS`
- Force scheduled benchmark workflow runs through OpenRouter with
`LLM_VENDOR=openrouter`, while preserving direct OpenAI support for
local/manual use.
- Improve benchmark publishing isolation:
- isolated SpacetimeDB CLI root per publish
- serialized C# benchmark publish concurrency
- local NuGet package references for generated C# benchmark projects
- Windows/PATH handling for TypeScript `pnpm`
- Update default benchmark model routes to current model names/ids.
- Update TypeScript golden answers for current SDK shape.
# API and ABI breaking changes
None.
This adds benchmark-runner/workflow behavior and CLI options, but does
not change SpacetimeDB runtime API or ABI.
# Expected complexity level and risk
3/5
The changes are mostly isolated to the LLM benchmark runner and GitHub
workflows, but the risk is moderate because they touch CI execution
paths, local SDK build assumptions, website-managed model resolution,
OpenRouter routing, and generated module publish behavior across Rust,
C#, and TypeScript.
The most sensitive pieces are:
- GitHub Actions workflow dispatch/manual input behavior.
- Remote model registry parsing from the website.
- C# benchmark publish behavior on the self-hosted runner.
# Testing
- [x] `cargo check -p xtask-llm-benchmark --bin llm_benchmark`
- [x] `cargo test -p xtask-llm-benchmark --bin llm_benchmark`
- [x] `cargo test -p xtask-llm-benchmark
parses_active_available_model_routes`
- [x] Manual GitHub Actions golden validation smoke runs for Rust, C#,
and TypeScript.
- [ ] Run a dry-run periodic benchmark workflow from this branch with
one explicit OpenRouter model, one task, and all languages.
- [ ] Run a website-dispatched dry-run benchmark and verify it sends
`model_set=explicit` plus selected model/task inputs.
---------
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@clockworklabs.io>
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
# Description of Changes
Thanks to @lisandroct for calling this miss out, with the update to 2.0
for Unreal I missed cleaning up the Blackholio tutorial from the pinned
1.12 version, this clears that up to work from the latest.
# API and ABI breaking changes
N/A
# Expected complexity level and risk
1 - docs only
# Testing
Double checked all the updated links
# Description of Changes
- Fix TypeScript connection examples to call `DbConnection.builder()`
without `new` and include `.build()`.
- Document reducer context random APIs across TypeScript, C#, Rust, and
C++.
- Align reducer skill determinism guidance with the documented
context-provided RNG API.
- Consolidates the work from #5403 and #5306 into the single daily docs
audit branch `bot/docs-audit`.
# API and ABI breaking changes
None. Documentation and agent skill guidance only.
# Expected complexity level and risk
1. This is a low-risk docs-only change plus one agent skill wording
update.
# Testing
- [x] `pnpm --dir docs build` passed. Docusaurus emitted the existing
`docusaurus-plugin-llms-txt` warning for `/docs/ask-ai/ask-ai`, then
generated static files successfully.
- [ ] Reviewer can check that the TypeScript connection snippets match
the SDK builder API.
- [ ] Reviewer can check that the reducer context RNG examples match the
supported APIs for each SDK.
---------
Co-authored-by: rain <rain@rain.local>
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
- Bumps version to 2.7.0
# 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 - this is just a version bump
<!--
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] Version number is correct (`2.7.0`)
- [x] BSL license file has been updated with the new date and version
number
# Description of Changes
Adds a Prometheus counter for client disconnects caused by the outgoing
WebSocket message queue reaching capacity.
The new metric is
`spacetime_client_outgoing_queue_disconnects_total{db=...}`. It
increments only on the `TrySendError::Full` path that kicks a client
after its bounded outgoing queue fills.
# API and ABI breaking changes
None.
# Expected complexity level and risk
1. This is a narrow observability change: one metric definition and one
increment at the existing kick site.
# Testing
- [x] `cargo fmt --all`
- [x] `LC_ALL=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 LANG=en_US.UTF-8 cargo
check -p spacetimedb-core`
- [x] `git diff --check`
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
# Description of Changes
- Added a client-side query builder for the Unreal SDK
- Added typed query-builder subscriptions for Unreal C++ via
SubscriptionBuilder.AddQuery(...).Subscribe()
- Added generated Blueprint query-builder support with source query
nodes, column nodes, predicates, Where, AddQuery, and Subscribe
- Added Blueprint autocasts at the AddQuery boundary so source-specific
Blueprint queries can connect cleanly into the generic subscription
builder for better devex in Blueprint
- Synced the Unreal query-builder core with the C++ module
implementation
- Updated the copied Unreal core query-builder headers to match the
shared C++
- Moved Unreal-specific literal/type adapters out of the shared core
copy and into Unreal-specific expansion code
- Added Unreal SDK test coverage and documentation for the new
query-builder surface
- Added new test harnesses to start to match the View/ViewPk tests
- Added documentation for the Unreal query builder
- Refactor generation for modules with more than 255 reducers, required
to get the TestClient back in working order
# API and ABI breaking changes
- No intended API or ABI breaking changes to released Unreal SDK
behavior
- Adds a new public client-side query-builder API to the Unreal SDK for
C++ and Blueprint
- Raw SQL subscriptions remain available
# Expected complexity level and risk
3 - Adds new query-builder surface with large changes to the code-gen,
the risk here is keeping the C++ module core mirrored to the SDK in the
future
# Testing
What I've done so far:
- [x] Updated and ran the following tests:
- [x] TestClientEditor
- [x] TestViewClientEditor
- [x] TestViewPkClientEditor
- [x] Ran the Unreal harness suites covering the query-builder client
paths
- [x] Verified the generated Unreal query-builder surface in both C++
and Blueprint testing supported fields with a small sample project
Should be done at least once by a reviewer:
- [ ] Re-run the full `sdk-unreal-test-harness` as it's disabled in CI
- [ ] Play with the C++ and Blueprint versions in a small Unreal project
---------
Signed-off-by: Jason Larabie <jason@clockworklabs.io>
Co-authored-by: Ryan <r.ekhoff@clockworklabs.io>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
# Description of Changes
HTTP handlers already have smoketest coverage, but in order to add to
`module-test`s all languages had to have parity as `module-test` has a
check to ensure schemas match.
The existing integration tests using `module-test` load SpacetimeDB in
memory, expanding these tests would require significant and potentially
ugly work to handle hosting for HTTP handlers. Instead, this PR adds
compile-only for each `module-test` with a matching handler + route.
# API and ABI breaking changes
N/A
# Expected complexity level and risk
1 - tiny addition to `module-test` for all languages
# Testing
- [x] `cargo test -p spacetimedb-schema module_test`
- [x] `cargo test -p spacetimedb-testing`
# Description of Changes
Adds primary keys to procedural views in C++. This mirrors the work from
#5111, #5246, and #5327 adding the feature and the docs changes.
# API and ABI breaking changes
None
# Expected complexity level and risk
3
# Testing
- [x] Equivalent tests as were added in #5111 and #5246 for rust,
typescript, and C#
# Description of Changes
Was forgotten while migrating to the QueryBuilder i suppose.
Closes#5073
Maybe @clockwork-tien could lend a hand again in reviewing? ^^
# 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
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
Works in my project :>
<!-- 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] Type Error goes away when using .eq(uuid)
---------
Co-authored-by: joshua-spacetime <josh@clockworklabs.io>
# Description of Changes
Fixes the `Release Notifications` workflow startup failure seen in
<https://github.com/clockworklabs/SpacetimeDB/actions/runs/27775721225/workflow>.
The internal announcement job referenced `needs: on-release`, but no
`on-release` job exists in `.github/workflows/tag-release.yml`, so the
workflow failed before scheduling any jobs. This removes the dangling
dependency and gates the internal Discord announcement to real `release`
events so manual `workflow_dispatch` dry runs do not try to send an
internal release announcement using missing release-event fields.
# API and ABI breaking changes
None. This only changes GitHub Actions configuration.
# Expected complexity level and risk
1 - Low complexity. The change is limited to one workflow job
dependency/condition.
# Testing
- [x] Parsed `.github/workflows/tag-release.yml` as YAML.
- [x] Checked that all remaining `needs:` targets in
`.github/workflows/tag-release.yml` refer to existing jobs.
- [x] Ran `git diff --check`.
- [ ] Optional reviewer check: run the workflow manually with the
default dry-run inputs after merge.
---------
Signed-off-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
# Description of Changes
Creates a new GitHub action that triggers any time a `Release` on the
SpacetimeDB repo changes to the `published` state.
When this triggers, the workflow will take information from that
release, and build a message from it, in the form of:
```
**SpacetimeDB ${RELEASE_TAG}**
View the full release notes:
${RELEASE_URL}
${RELEASE_BODY}
```
And send that message to the SpacetimeDB Public Discord Webhook.
Note: This PR itself does not setup or configure the Discord Webhook,
and relies on the Webhook URL already being available.
# API and ABI breaking changes
No API or ABI changes, this is only related to GitHub tooling.
# Expected complexity level and risk
1 - Low complexity. The only risk is in sending garbage messages to the
Discord URL if this automation is improperly configured.
# Testing
- [X] Ran a local version of similar code to test formatting. No testing
of this GitHub Action has been performed.
---------
Signed-off-by: Ryan <r.ekhoff@clockworklabs.io>
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
# Description of Changes
Removes all references to `Promise.withResolvers` from the codebase
since it's not supported universally and replaces it with the classic
pre-ES2024 deferred pattern. See #5031 and #5342.
Also adds a lint to avoid re-introducing it in the future.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
...
# Description of Changes
Adds a merge-queue fast path for CI when the synthetic merge-group
commit has the same tree as the queued PR head.
The new `merge_queue_noop` job parses the PR number from the merge-group
ref, resolves the PR head SHA, and compares that tree to `GITHUB_SHA`.
If there is no diff, the expensive CI jobs are skipped as duplicate
work. Matrix jobs with required per-matrix check names get lightweight
no-op counterparts so branch protection still sees the expected
successful check names.
# API and ABI breaking changes
None.
# Expected complexity level and risk
2. This is limited to GitHub Actions wiring, but it interacts with merge
queue semantics and required check names. The implementation
intentionally falls back to normal CI if it cannot parse the PR number
or resolve the PR head.
# Testing
- [x] Parsed `.github/workflows/ci.yml` with Ruby YAML.
- [x] Ran `git diff --check`.
---------
Signed-off-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
# Description of Changes
Refactors the Rust smoketest helper surface so publish and subscribe
variants use builders instead of parallel helper methods.
- Replaces `publish_module*` helper variants with `Smoketest::publish()`
and fluent options for name, clear, current database, break clients,
stdin, replicas, organization, and source modules.
- Replaces `subscribe_*` / `subscribe_background*` variants with
`Smoketest::subscribe(...).expect_rows(...).confirmed(...).background()`.
- Updates smoketest call sites to the builder APIs.
# API and ABI breaking changes
Internal smoketest helper API change only. No product API or ABI
changes.
# Expected complexity level and risk
2
This touches many smoketest call sites, but the underlying CLI command
behavior remains centralized in the same helper internals.
# Testing
- [x] Existing CI passes
---------
Signed-off-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
# Description of Changes
This is an attempt at fixing a SIGABRT that sometimes happens when
running the standalone integration tests.
It's not clear exactly what causes it, however one thing that may have
contributed to it was that previously the tests did not initiate a clean
shutdown of the database.
Some modules schedule repeating work in `init`, and it's not obvious to
me that in flight operations will exit cleanly if we just drop all of
the database/runtime handles at once.
# API and ABI breaking changes
N/A
# Expected complexity level and risk
1
# Testing
This is a testing fix.
# Description of Changes
- spacetime init --template without arg prints templates list and link
to website
# Screenshot
<img width="696" height="392" alt="screenshot"
src="https://github.com/user-attachments/assets/98e87537-554b-411b-96ab-3ceb9a6a9d45"
/>
<!-- Please describe your change, mention any related tickets, and so on
here. -->
# 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
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] I tested the changes
# Description of Changes
Closes#5250#4636 introduced a regression where the ProcedureContext used to include
the sender and connection_id from the caller while now it is always
empty (which is wrong)
Correct it.
Also fully migrate to `database_identity` which was forgotten about so i
deprecated it for procedures (since they are now stable) and just
changed it for HttpHandlers (because they are still unstable)
@gefjon since you did the lil woopsie (ugh pinging you again lol hope im
not annoying haha)
# API and ABI breaking changes
Breaking the HttpHandler function which is unstable.
Restoring behaviour of 2.3 which got lost with 2.4.
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
# Expected complexity level and risk
1. Trivial refactoring
<!--
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] The caller identity is there again for Procedures.
---------
Signed-off-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
Co-authored-by: joshua-spacetime <josh@clockworklabs.io>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
# Description of Changes
Reviewing recent benchmark runs, it appears that #5071 probably
regressed TPS by around 3-5%. I don't want to revert that change because
it has implications for replication, and so for now we'll just live with
the slight regression.
# API and ABI breaking changes
None
# Expected complexity level and risk
0
# Testing
N/A
# Description of Changes
Attempted to fix this test in #5343, but we're still getting SIGKILLS,
so ignoring for now. This will require more investigation to fix. I've
included what I believe is the reason in the help text and created
[this](#5362) tracker to unskip.
# API and ABI breaking changes
None
# Expected complexity level and risk
0
# Testing
N/A
# Description of Changes
Use an isolated server process per SDK test instead of a single process
for all of the tests. In addition to reducing the memory footprint of
each test run, this should also allow for more parallelism among the
individual tests.
# API and ABI breaking changes
None
# Expected complexity level and risk
1.5
# Testing
The SDK test suite should continue to work
# API and ABI breaking changes
None. Docs-only change.
# Expected complexity level and risk
1 - trivial documentation fix, no code or behaviour change.
# Testing
- [x] Confirmed accessor names against the SDK source:
`database_identity()` (Rust/C++), `databaseIdentity` (TS),
`DatabaseIdentity` (C#); the old forms are marked deprecated/obsolete in
bindings.
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
The reducer-context cheat-sheet and the "Context Properties Reference"
tables still listed `ctx.identity` / `ctx.identity()` as the accessor
for the module's own identity. That accessor was deprecated in favour of
`databaseIdentity` / `database_identity()` / `DatabaseIdentity`, and the
troubleshooting guide added in c70d00246 (#5142) documented the
deprecation but missed updating these other references — these stray
updates should have landed there. This brings all four language tabs in
line with the non-deprecated accessor.
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
## What changed
Adds an explicit checkout step before `dorny/paths-filter` in the
Internal Tests workflow.
## Why
`dorny/paths-filter@v3` needs a git working tree for `push` events. The
Internal Tests workflow ran it before any checkout, so every `push` run
on `master` failed immediately in `Detect non-docs changes` with:
```text
fatal: not a git repository (or any of the parent directories): .git
```
This only showed up consistently on `master` because those runs are
`push` events. On `pull_request` events, `dorny/paths-filter` can use
the GitHub pull request files API with the PR number, so it does not
need a local checkout for the same file detection path.
Adding checkout gives the action a repository when it handles `push`
events, while leaving PR behavior unchanged.
## Testing
- `git diff --check`
- PR #5295 `Internal Tests` job completed `Checkout` and `Detect
non-docs changes` successfully, then moved on to private dispatch/wait.
---------
Signed-off-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
We believe this docker build is completely unused. This docker container
is different than the docker build that we send out for releases which
is the one users actually end up using. This specific docker build used
to be for internal deploys but we have not used it in a very long time
now, probably more than a year or two.
# API and ABI breaking changes
None - this is just a CI change.
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
# Expected complexity level and risk
1 - just a CI 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! -->
- Not tested but we sync'd on this in the discord and there were no
objections from the devops team or @joshua-spacetime .
---------
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
This removes the `spacetimedb-update` check specifically on arm. This
test doesn't have a whole lot of value because we're already covering
Linux + Windows on x86 and then macOS on aarch64. Removing this will
allow us to decom the arm runner.
# API and ABI breaking changes
<!-- If this is an API or ABI breaking change, please apply the
corresponding GitHub label. -->
None - just a CI change
# 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! -->
- I have not tested this but me and Zeke sync'd on this and we think it
makes sense.
Julien Lavocat