# Description of Changes
This PR:
- standardizes the prettier config across all TypeScript projects
- adds a root level package.json
- standardizes all `pnpm` commands to be the same
- updates documentation accordingly
- adds some additional typescript testing for serialization and
deserialization
**IMPORTANT!** Once this PR merges we will need to change the
`compile-and-test` required check to `build-and-test`
# API and ABI breaking changes
No breaking changes.
# Expected complexity level and risk
2 - It in principle doesn't change any code, but could affect deploy
processes.
# Testing
- [x] Just the automated testing that we had previously
- [x] I added additional automated tests
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
Please note, much of the code changed in this PR is generated code.
This change updates the TypeScript SDK to use a new `spacetimedb`
TypeScript library which lives under the `/crates/bindings-typescript`
folder alongside `/crates/bindings-csharp`. Just like with the C#
bindings library, the types for `AlgebraicType` and `RawModuleDef` are
now code generated with a script in `/crates/codegen/examples`.
Pulling this out into a library allows us to use the same types and
serialization code on both the server and the client for TypeScript
modules.
In the process of making this change I also found and fixed several
issues with the TypeScript code generation. Namely an issue with
recursive types and an issue with the `never` type. I also removed any
use of `namespace`s since those are a TypeScript only feature, and we
want to have JavaScript + types so that we can use the generated code
with ESBuild without TSC.
I have also improved the npm/pnpm scripts to be able to generate
TypeScript code for us automatically by running `pnpm generate` for any
place that we have to generate typescript code. Namely:
- Quickstart module bindings
- AlgebraicType/ModuleDef for TypeScript module library
- Client API messages for the TypeScript API
- TestApp module bindings
# API and ABI breaking changes
IMPORTANT! This is an API breaking change for clients, as such it should
be a major version change. However, I am going to see if I can shim in
the old API as best as possible to make it compatible.
Notably, we were previously exporting APIs that end users do not need,
and I don't think it would ever occur to them to use, namely the whole
`AlgebraicValue` API and also the `AlgebraicType` API. In principle, no
one should have a need for these, although it was technically possible
for them to use it.
Indeed, we could potentially even just remove AlgebraicType completely
from the API by directly code generating the serialization code.
Listed below are all of the **BREAKING** changes to the API and their
effect:
- `AlgebraicType` is now a structural union literal type instead of a
class (nominal type), this is a consequence of generating the type with
our code gen. Users did not have a reason to use `AlgebraicType`
directly.
- The `AlgebraicValue` type has been removed entirely. This was
previously a class that was exported from the SDK, but very unlikely to
be used by users.
- The `ProductValue` type has been removed.
- The `ReducerArgsAdapter` and `ValueAdapter` types, which were used
with AlgebraicValues have been removed.
- Generated code has changed incompatibly so users will have to
regenerate code when upgrading to this version. Technically a breaking
change, but pretty easy to fix.
Listed below are the non-breaking API changes:
- I am now exporting generated product types as the default export in
addition to how I was exporting them before
- For generated sum type `T`, I am now exporting a `TVariants` namespace
which has the types of all the variants for `T`. This was previously
exposed on the namespace `T`, but was inaccessible in modules other than
the one it was defined in because I also export a type `T` in addition
to namespace `T` and in the type position `T` was being interpreted as a
type rather than a namespace. It's unclear why TypeScript resolved it as
the `T` namespace within the module in which is was defined previously.
Anyway, since the old types were apparently unobservable to users, I've
replaced them with the types in `TVariants`. (Open to other names for
this namespace).
- I fixed a bug where never types (sum types with no variants) were not
correctly generated.
# Expected complexity level and risk
3. The most complex thing about the PR are the potential impacts to the
API. I am reasonably certain, but not 100% certain that I have accounted
for everything above.
# Testing
- [x] I ran `pnpm test` which runs all the tests in the repo including
an integration test which tests the connection to SpacetimeDB. I also
fixed broken tests.
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
For V8 modules:
- Add `call_call_reducer`
- Add stack traces for traps.
- Wire `update_database`
It remains to wire up `call_call_reducer`, but this shouldn't be that
much work, but I'll do that in a follow up.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
Tests for `call_call_reducer` are added.
# Description of Changes
Title. When validating column type changes in `Table::change_columns_to`
and comparing layouts in `RowTypeLayout::is_compatible_with`, return
structured error objects which describe the mismatch.
I made this change while debugging the issue that led to #3203 , where
`change_columns_to` returned an error during replay of an automigration
which had succeeded the first time. The original error contained enough
information to debug, but it was presented in a noisy and unhelpful way,
so I wrote this patch to get better diagnostics.
Per @Centril 's comments, these errors are for internal assertions, not
user-facing error reporting, so we value fail-fast rather than error
hygiene and choose not to use the `ErrorStream` combinator.
Also note that I sprinkled `Box`es around some large-ish error types to
quiet
https://rust-lang.github.io/rust-clippy/master/index.html#result_large_err
.
# API and ABI breaking changes
N/a
# Expected complexity level and risk
1.
# Testing
Manual testing with BitCraft. As this is purely altering the error
reporting for non-user-facing assertions, I don't believe any further
testing is necessary.
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
- Simple patch version bump. Because we forgot to bump the version
number for 1.3.1 this is bumping from 1.3.0 => 1.3.2
# API and ABI breaking changes
0
# Testing
- Verified that the version number in the license has been updated
- Verified the output of `spacetime --version`:
```
$ spacetime --version
spacetime Path: C:\Users\boppy\AppData\Local\SpacetimeDB\bin\current\spacetimedb-cli.exe
Commit: 0027d094e1
spacetimedb tool version 1.3.2; spacetimedb-lib version 1.3.2;
```
---------
Signed-off-by: John Detter <4099508+jdetter@users.noreply.github.com>
# Description of Changes
Closes#2100
Replay the `quickstart-chat` guide steps for the `Rust/C#` client &
server, and confirm the connection and `set_name`, `send_message`
commands.
# Expected complexity level and risk
1
# Testing
- [x] Added a smoke test
# Description of Changes
In `st_column_changed`, `iter_st_column_for_table` returns rows in
physical storage order. In simple cases (without unrelated deletes) this
will be the same as insertion order, and therefore also the same as
sorted order, but in cases with multiple column-changing automigrations
the physical storage order of the rows diverges from the correct sorted
order. Because this isn't a hot path, we can just call `.sort()` and not
worry about it.
# API and ABI breaking changes
N/a
# Expected complexity level and risk
1
# Testing
None yet. Needs manual testing with BitCraft update.
---------
Signed-off-by: Mazdak Farrokhzad <twingoow@gmail.com>
Co-authored-by: Mazdak Farrokhzad <twingoow@gmail.com>
Co-authored-by: Shubham Mishra <shubham@clockworklabs.io>
# Description of Changes
Uncommented out code from test, in order to have "delete row by index"
test of C# module code ran.
This is the implementation of a fix for issue
https://github.com/clockworklabs/SpacetimeDB/issues/2233
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
- [X] Ran `dotnet run` and `dotnet test`, both returned no errors.
# Description of Changes
To address user issue
https://github.com/clockworklabs/SpacetimeDB/issues/2647 , the C#
implementation of quickstart-chat files and documentation have been
updated to pattern match the variable assignment of User.
This has the benefit of the variables never being perceived by the
analyzers as a nullable types.
# API and ABI breaking changes
Not API breaking
# Expected complexity level and risk
1
# Testing
- [X] Tested updated module code locally, following instructions from
the documentation.
Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com>
# Description of Changes
Fixes
https://github.com/orgs/clockworklabs/projects/22?pane=issue&itemId=102392974&issue=clockworklabs%7Ccom.clockworklabs.spacetimedbsdk%7C276
by renaming `internal` `static` serializer fields so that they do not
overlap with user-provided names.
Note, however, that some field names still will not work: `ReadFields`,
`WriteFields`, `Equals`, and `GetHashCode`.
This would require a separate fix since the error would happen in a
different place. In this case we would need to change the name of the
generated member to something like `ReadFields_` or `Equals_`, which I'm
not sure is a good idea.
# API and ABI breaking changes
N/A
# Expected complexity level and risk
0
# Testing
SDK tests and `dotnet-verify` tests are passing.
---------
Signed-off-by: rekhoff <r.ekhoff@clockworklabs.io>
Co-authored-by: rekhoff <r.ekhoff@clockworklabs.io>
# Description of Changes
First commit reverts disabling adding enum variants
(https://github.com/clockworklabs/SpacetimeDB/pull/3178).
Second commit makes replay recognize inserts / deletes to `st_column`
and triggers a refresh of the in-memory table that was referenced in the
`st_column` change.
# API and ABI breaking changes
None
# Expected complexity level and risk
3, small code bug "deep".
# Testing
I've confirmed manually that a module that couldn't be restarted before
this PR can now be restarted.
We should probably follow up this PR with a smoketest.
# Description of Changes
Apparently, I missed several license files in #3002. I'm not sure what
method I was using to find them, but apparently it was insufficient.
**This replaces all empty `LICENSE` files with an explicit (symlink to)
BSL license, and all apache licenses with symlinks to the root apache
license.** This PR does not intentionally change any license terms, so
if you see one that changed, **it's a mistake**.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
```bash
$ find . -name '*LICENSE*' -type f | grep -v '\.meta$'
./crates/sqltest/standards/LICENSE # this one is an external library that we are not allowed to re-license
./LICENSE.txt # this is the root license
```
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
Add a RemoteQuery regression test to C# SDK to address issue:
https://github.com/clockworklabs/SpacetimeDB/issues/3064
This adds on to existing regression tests, creating a rather small
change.
# API and ABI breaking changes
Not breaking change
# Expected complexity level and risk
1
# Testing
- [X] Ran `dotnet test`, all tests pass
# Description of Changes
This enables smoketests to run against remote servers, such as maincloud
/ maincloud staging.
I also added a `--spacetime-login` param, for servers that require a
"proper" spacetime login (such as both servers above).
Usage:
```bash
python3 -m smoketests \
--remote-server https://maincloud.staging.spacetimedb.com \
--spacetime-login \
-x replication # for some reason this is required, even though I swear it should be disabled by not passing `--docker`
```
# API and ABI breaking changes
None. CI only.
# Expected complexity level and risk
1
# Testing
- [x] Smoketests pass on this PR
- [x] Smoketests pass when run against maincloud staging (using the
instructions above)
- [x] Manual review to check whether I've accidentally de-fanged any
"test for negative case" tests
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
`fn alter_table_row_type` now writes the new row type to `st_column`.
This is not a fix for the adding-variants problem, but it does get us
closer.
# API and ABI breaking changes
None
# Expected complexity level and risk
2, system tables stuff is always risky.
# Testing
`test_alter_table_row_type_is_transactional` is amended with assertions.
# Description of Changes
We had weird caching issues in the C#/Unity testsuite. Somehow, they got
triggered only as of
https://github.com/clockworklabs/SpacetimeDB/pull/3181 merging, and I
have no idea why/how.
I've restored the `id` field of the checkout step (which is used by the
cache step), and this _seems_ to have fixed it.
# API and ABI breaking changes
None.
# Expected complexity level and risk
1
# Testing
- [x] It passes on this PR
- [x] It passes in a test PR that combines this change with
https://github.com/clockworklabs/SpacetimeDB/pull/3182
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
Refactors the machinery of call_reducer and update_database to
a) have smaller pieces that make up the whole so that the code becomes
clearer
b) extract all the VM-independent stuff so that it can be reused by V8
modules.
This is best reviewed commit by commit.
# API and ABI breaking changes
None.
# Expected complexity level and risk
2, it's an important place, but this is doing just code motion.
# Testing
No semantic changes, just code motion.
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
Disables automigrations for column type changes
# 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. -->
0
# 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] Updated smoketests
# Description of Changes
Iterating over a HashMap does not guarantee any ordering of the items.
To ensure consistent and predictable pretty-printing, explicitly sort
entries.
# API and ABI breaking changes
NA
# Expected complexity level and risk
0
# Description of Changes
This obscured other used code, so let's remove it as its dead.
# API and ABI breaking changes
None
# Expected complexity level and risk
-1
# Testing
Not applicable.
# Description of Changes
I'm moving `crates/sdk` to `sdks/rust` to be more in line with where the
rest of our SDKs are listed. I updated the corresponding paths etc. that
pointed to the previous location.
This PR is based on
https://github.com/clockworklabs/SpacetimeDB/pull/3185, because if we
merge this without that, our release scripts will be broken.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
- [x] Existing CI passes
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
I updated `tools/publish-crates.sh` and `tools/find-publish-list.py` to
be more flexible to where our crates can be located (rather than
hardcoding `crates/foo`). This is in preparation for
https://github.com/clockworklabs/SpacetimeDB/pull/3181.
Now, `find-publish-list.py` loads the output of `cargo metadata` to
dynamically find the path of the crate in question. This also allows us
to "properly" determine which crates are ours, instead of the
`spacetimedb-` string prefix check that we were doing before.
It also now supports `--directories` to output directory paths, rather
than just crate names. `publish-crates.sh` now uses those output paths
rather than assuming that it knows where to find crates.
As a bonus, this approach is also much faster (~0.3s to find the crate
list, vs ~8 before to load and process all the tomls).
# API and ABI breaking changes
None
# Expected complexity level and risk
2
# Testing
- [x] `find-publish-list.py` lists the same crates before and after:
```bash
$ ( git checkout master && python3 tools/find-publish-list.py --recursive --quiet bindings sdk cli standalone > before.txt )
$ ( git checkout bfops/flexible-publish-scripts && python3 tools/find-publish-list.py --recursive --quiet spacetimedb spacetimedb-sdk spacetimedb-cli spacetimedb-standalone > after.txt )
# the new script prints out crate names rather than directory names, so we need to tweak a bit
$ diff -U2 before.txt <(cat after.txt | sed 's/^spacetimedb-//' | sed 's/^spacetimedb$/bindings/')
--- before.txt 2025-08-20 10:18:07.323217870 -0700
+++ /dev/fd/63 2025-08-20 10:35:38.344074842 -0700
@@ -8,17 +8,17 @@
data-structures
schema
-table
-expr
-physical-plan
paths
fs-utils
commitlog
+table
durability
-execution
+expr
+physical-plan
snapshot
+execution
client-api-messages
query
-subscription
vm
+subscription
datastore
auth
```
Some lines are reordered because we find dependencies via metadata
instead of toml now - I spot-checked some of the moved lines to see
whether they were in an invalid place, and I did not find any evidence
of that.
- [x] `--directories` flag prints correct directories instead of names
```bash
$ python3 tools/find-publish-list.py --directories --quiet --recursive spacetimedb-sdk
/home/lead/work/clockwork-localhd/SpacetimeDBPrivate/public/crates/memory-usage/Cargo.toml
/home/lead/work/clockwork-localhd/SpacetimeDBPrivate/public/crates/primitives/Cargo.toml
/home/lead/work/clockwork-localhd/SpacetimeDBPrivate/public/crates/metrics/Cargo.toml
/home/lead/work/clockwork-localhd/SpacetimeDBPrivate/public/crates/bindings-macro/Cargo.toml
/home/lead/work/clockwork-localhd/SpacetimeDBPrivate/public/crates/sats/Cargo.toml
/home/lead/work/clockwork-localhd/SpacetimeDBPrivate/public/crates/lib/Cargo.toml
/home/lead/work/clockwork-localhd/SpacetimeDBPrivate/public/crates/client-api-messages/Cargo.toml
/home/lead/work/clockwork-localhd/SpacetimeDBPrivate/public/crates/data-structures/Cargo.toml
/home/lead/work/clockwork-localhd/SpacetimeDBPrivate/public/crates/sdk/Cargo.toml
```
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
This adds auto migration support to the `schema` crate.
Additional changes are needed to fully implement this feature: see
https://github.com/clockworklabs/SpacetimeDB/issues/2912
# API and ABI breaking changes
None
# Expected complexity level and risk
1, at this level the change is fairly straightforward. The integration
will be more difficult.
# Testing
Added `schema` unit tests for success/failure cases.
---------
Co-authored-by: Shubham Mishra <shivam828787@gmail.com>
# Description of Changes
fixes#3174 .
During initialization, entries were added to the `DelayQueue` but not to
`key_map`.
### Detailed Explanation:
1. `DelayQueue` is **not set-semantic**, so we track uniqueness with a
`key_map: FxHashMap` but that wasn't updated during initiliaziation.
2. `Scheduler::schedule` is **not transactional**: it enqueues reducers
even if the DB transaction later fails (abort, duplicate row, etc.). On
yield, `SchedulerActor` checks the DB before execution.
**Combined Effect**: A transaction that does not actually change a
scheduled entry but still calls `Scheduler::schedule` after a module
update will cause a duplicate entry in the `DelayQueue`, since `key_map`
does not yet contain that entry.
**Why It Didn’t Show Earlier**:
When a repeating reducer executes, we re-schedule it by updating both
`DelayQueue` and `key_map` correctly.
The bug only appears in the window after updating module but before the
first execution, if a transaction calls schedule without actually
modifying the DB row.
Which was indeed happening as per discord chat:
> but yeah most likely order of event was modue was updated
> and then update_scheduled_timers_from_static_data was called
window between update module and first execution is 1 hour for this
case.
## Repo steps:
1. publish this module, it makes `send_scheduled_message` reducer to be
called every 10 secs.
```rust
#[spacetimedb::table(name = scheduled_message, public, scheduled(send_scheduled_message))]
pub struct ScheduledMessage {
#[primary_key]
#[auto_inc]
scheduled_id: u64,
scheduled_at: ScheduleAt,
}
#[spacetimedb::reducer]
fn send_scheduled_message(ctx: &ReducerContext, sched: ScheduledMessage) -> Result<(), String> {
info!("Sending scheduled message: {:?}", ctx.timestamp);
Ok(())
}
#[spacetimedb::reducer(init)]
pub fn init(ctx: &ReducerContext) {
ctx.db.scheduled_message().insert(ScheduledMessage {
scheduled_id: 0,
scheduled_at: Duration::from_secs(10).into(),
});
}
#[spacetimedb::reducer]
pub fn update_timer(ctx: &ReducerContext) {
for mut timer in ctx.db.scheduled_message().iter() {
timer.scheduled_at = Duration::from_secs(10).into();
ctx.db.scheduled_message().scheduled_id().update(timer);
log::info!("building decay agent timer was updated");
}
}
```
2. Update module to support automigration (add a table) and re-publish
it.
3. Call reducer `update_timer` and do it before first execution of
`send_scheduled_message` after updating module.
4. As `update_timer` doesn't change the existing scheduler but calls
`Scheduler::schedule` it will cause duplicate entry in `DelayQueue`.
# API and ABI breaking changes
N/A
# Expected complexity level and risk
1, pretty obvious fix.
# Testing
manually.
The code fix is straightforward, but the issue only becomes visible
under specific conditions.
# Description of Changes
This change adds the following `System.TimeSpan`-style static
construction methods to `SpacetimeDB.TimeDuration`:
* `static TimeDuration FromMilliseconds(double milliseconds)`
* `static TimeDuration FromSeconds(double seconds)`
* `static TimeDuration FromMinutes(double minutes)`
* `static TimeDuration FromHours(double hours)`
* `static TimeDuration FromDays(double days)`
These mirror the equivalently named static methods on `System.TimeSpan`
and dramatically improve usability and familiarity for experienced C#
users with no more overhead than the user performing the multiplication
themselves.
Wish I'd thought to do this before v1.1.2 got released. Ah well.
# API and ABI breaking changes
None. Convenience methods added in bindings only.
# Expected complexity level and risk
1 (potentially up to a low 2 if cleanup is desired elsewhere in the
bindings to leverage these new methods).
# 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] Ensure the changes build. <!-- maybe a test you want to do -->
- [ ] New contributor check! Review to make sure repo style & substance
standards are complied with. <!-- maybe a test you want a reviewer to
do, so they can check it off when they're satisfied. -->
# Description of Changes
<!-- Please describe your change, mention any related tickets, and so on
here. -->
We stopped incrementing the incoming queue length metric. This patch
increments it again and adds a regression test.
# 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
# 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] Regression test
# Description of Changes
Closes#3170 .
Commit messages:
### Increase the default incoming-queue-length limit
2048 turned out to be too low a value for BitCraft, as their world
upload process requests on the order of 6000 reducers very rapidly. We
still feel that having a limit is valuable to prevent malicious or
misguided clients from taking an arbitrarily large amount of host
memory, so we bump the value to give us a wide safety error for
BitCraft's needs but don't remove the limit entirely.
### Add log at `warn` when the host disconnects a client due to too many
requests
# API and ABI breaking changes
N/a
# Expected complexity level and risk
1
# Testing
- [x] @mamcx to run a BitCraft bot test.
# Description of Changes
Defines a building piece `call_describe_module` that can be used to call
the expected ABI function `describe_module` in JS.
There might be further changes to this but this is a first working pass
at it.
# API and ABI breaking changes
None
# Expected complexity level and risk
2, this does not integrate with existing code reachable in production,
but the exception handling required some googling/reading docs.
# Testing
A test `call_describe_module_works` is added that tests returning an
empty `RawModuleDef` from JS.
The `Clone` impl for `ClientConnection` would create an independent
instance that could not observe module hotswapping. This would result in
methods called on a replaced `ModuleHost` to fail, because that host
exited already.
Fix by reading the `ModuleHost` from the watch channel directly, instead
of maintaining a redundant copy.
Also fix `watch_module_host` to properly mark the current module host as
seen.
# Expected complexity level and risk
2
# Testing
- [x] test suite passes
- [x] ran @bfops repro script
# Description of Changes
We recently merged several repos together. This PR clarifies the license
terms for several subdirectories, as well as the relationship between
the licenses.
The licenses in our subdirectories have become symbolic links to
licenses in our toplevel `licenses` directory. For any particular
subdirectory's license file in the diff, you can click `... -> View
file` and then click on the text that says "Symbolic Link" on that page.
This will take you to the license file that it links to.
I have also updated the `tools/upgrade-version` script to update the
change date in the new `licenses/BSL.txt` file.
# API and ABI breaking changes
None.
# Expected complexity level and risk
1
# Testing
None. Only changes to license files.
---------
Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
# Description of Changes
This does 2 things:
1. simplifies the deserialization of optional sums so that they are
treated as regular sums.
2. adds higher level v8 ser/de interfaces and privatizes what can be
private.
# API and ABI breaking changes
None
# Expected complexity level and risk
1
# Testing
Existing ser/de tests are adjusted to use the new interfaces.
# Description of Changes
Fixes a Typescript SDK bug where onclose of WebsocketDecompressAdapter
is never called
# 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
Potential risk as Typescript SDK consumers might be currently relying
only on onConnectError to report disconnection. Users should instead use
onDisconnect, or can simply subscribe to both callbacks with the same
function again to get the same functionality.
<!--
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. -->
This is a trivial change, but could have minor repercussions on current
code. I'd still say it's a level 1 change, with consumers able to easily
change to the correct callback.
# 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! -->
# Description of Changes
Updated outdated repository link in documentation from
`https://github.com/ClockworkLabs/tree/master/demo/Blackholio`
to
`https://github.com/clockworklabs/SpacetimeDB/tree/master/demo/Blackholio`
to reflect the current location of the Blackholio demo.
# API and ABI breaking changes
None.
# Expected complexity level and risk
Complexity level: **1** (trivial change)
This is a simple documentation update with no impact on code execution,
APIs, or ABIs.
# Testing
Verified that the new link is valid and accessible.
No additional testing required.
* [ ] Reviewer can confirm that the new link resolves correctly.
# Description of Changes
As requested by @gefjon
Most of this is:
- `'a` -> `'this`
- `'s` -> `'scope`
# API and ABI breaking changes
None
# Expected complexity level and risk
0
# Testing
No semantic changes.
# Description of Changes
On databases with many already-compressed snapshots, this was leading to
log spam without providing any useful information.
# API and ABI breaking changes
N/a
# Expected complexity level and risk
1
# Testing
N/a
# Description of Changes
- Previous to this PR if you login, create a player, then logout and log
back in you are prompted for a username again instead of just resuming
your gameplay. This is confusing to players because it seems like your
token is not being reused and you are just creating a new player.
# API and ABI breaking changes
None
# Expected complexity level and risk
1 - this is a demo change but technically affects the testsuite
# Testing
1. Clear your token, then open the game, create a player. Then logout
2. Without clearing your token, log back into the game.
3. Make sure that:
- Your username is correct
- Your circles are where you left them (and the amount of circles is
correct.)
Adds methods and free-standing functions to allow folds to stop at an
upper
bound, by passing a range instead of only a start offset.
# Expected complexity level and risk
1
# Testing
# Description of Changes
Currently with the function maybe_log_error to log errors we hide the
real source line where the error happened. So to still have the same
logic but with more accurate source line, I moved it to a macro to have
the same abstraction for logging.
# API and ABI breaking changes
-
# Expected complexity level and risk
1
# Testing
- [ ] I have tested it my application and it now show the better source
line of the log message
---------
Signed-off-by: ResuBaka <ResuBaka@users.noreply.github.com>
Co-authored-by: Phoebe Goldman <phoebe@goldman-tribe.org>
Tyler Cloutier