-
Notifications
You must be signed in to change notification settings - Fork 677
Merge master into 2.0 breaking changes #4117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge master into 2.0 breaking changes #4117
Conversation
the TS reference was slightly missing. you need assign a variable to the reducer to call it cross context # Description of Changes slight reference fix Signed-off-by: kormann <49917710+DKormann@users.noreply.github.com>
# Description of Changes Removes 1.5.0 DLLs from repo # API and ABI breaking changes Unity will complain locally until you regenerate the DLLs # Expected complexity level and risk 1 - Trivial # Testing - [x] Confirm CI pass - [X] Local tests are passing --------- Signed-off-by: Ryan <r.ekhoff@clockworklabs.io> Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com> Co-authored-by: John Detter <4099508+jdetter@users.noreply.github.com> Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
# Description of Changes Try fixing this again? It seems to pass on PRs if re-run. # API and ABI breaking changes None. # Expected complexity level and risk 1 # Testing - [x] It passes on this PR now 🤷 --------- Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com> Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
|
/update-llm-benchmark |
LLM Benchmark Results (ci-quickfix)
Compared against master branch baseline Generated at: 2026-01-24T00:05:38.779Z Failure Analysis (click to expand)Benchmark Failure AnalysisGenerated from: Summary
SpacetimeDB Benchmark Failures AnalysisRust / rustdoc_json FailuresCompile/Publish Errorst_002_scheduled_tableThe generated code: use spacetimedb::{table, reducer, ReducerContext, Table, ScheduleAt};
#[table(name = tick_timer, scheduled(reducer = tick, column = scheduled_at))]
pub struct TickTimer {
#[primary_key]
#[auto_inc]
scheduled_id: u64,
scheduled_at: ScheduleAt,
}
#[reducer(init)]
pub fn init(ctx: &ReducerContext) {
if ctx.db.tick_timer().count() == 0 {
ctx.db.tick_timer().insert(TickTimer {
scheduled_id: 0,
scheduled_at: ScheduleAt::repeat(50_000u64),
});
}
}
#[reducer]
pub fn tick(_ctx: &ReducerContext, _scheduled_id: u64) {
}The golden example: use spacetimedb::{reducer, table, ReducerContext, ScheduleAt, Table};
use std::time::Duration;
#[table(name = tick_timer, scheduled(tick))]
pub struct TickTimer {
#[primary_key]
#[auto_inc]
pub scheduled_id: u64,
pub scheduled_at: ScheduleAt,
}
#[reducer]
pub fn tick(_ctx: &ReducerContext, _row: TickTimer) -> Result<(), String> {
Ok(())
}
#[reducer(init)]
pub fn init(ctx: &ReducerContext) -> Result<(), String> {
ctx.db.tick_timer().insert(TickTimer {
scheduled_id: 0,
scheduled_at: ScheduleAt::Interval(Duration::from_millis(50).into()),
});
Ok(())
}The error: Explain the difference:
Root cause: The documentation may lack clarity on the specific types and return values required, especially around scheduling and reducers. Recommendation:
t_017_scheduled_columnsThe generated code: use spacetimedb::{table, reducer, ReducerContext, Table, ScheduleAt};
#[table(name = tick_timer, schedule(reducer = tick, column = scheduled_at))]
pub struct TickTimer {
#[primary_key]
#[auto_inc]
scheduled_id: u64,
scheduled_at: ScheduleAt,
}
#[reducer(init)]
pub fn init(ctx: &ReducerContext) {
let tbl = ctx.db.tick_timer();
if tbl.count() == 0 {
tbl.insert(TickTimer {
scheduled_id: 0,
scheduled_at: ScheduleAt::RepeatMicros(50_000),
});
}
}
#[reducer]
pub fn tick(_ctx: &ReducerContext, _row: TickTimer) {
}The golden example: use spacetimedb::{reducer, table, ReducerContext, ScheduleAt, Table};
use std::time::Duration;
#[table(name = tick_timer, scheduled(tick))]
pub struct TickTimer {
#[primary_key]
#[auto_inc]
pub scheduled_id: u64,
pub scheduled_at: ScheduleAt,
}
#[reducer]
pub fn tick(_ctx: &ReducerContext, _schedule: TickTimer) {
}
#[reducer(init)]
pub fn init(ctx: &ReducerContext) {
let every_50ms: ScheduleAt = Duration::from_millis(50).into();
ctx.db.tick_timer().insert(TickTimer {
scheduled_id: 0,
scheduled_at: every_50ms,
});
}The error: Explain the difference:
Root cause: There is likely a mismatch in expected vs. generated syntax, particularly around the scheduling configuration settings. Recommendation: Other Failurest_001_basic_tablesThe generated code: use spacetimedb::ReducerContext;
#[spacetimedb::table(name = user)]
pub struct User {
#[primary_key]
id: i32,
name: String,
age: i32,
active: bool,
}
#[spacetimedb::table(name = product)]
pub struct Product {
#[primary_key]
id: i32,
title: String,
price: f32,
in_stock: bool,
}
#[spacetimedb::table(name = note)]
pub struct Note {
#[primary_key]
id: i32,
body: String,
rating: i64,
pinned: bool,
}
#[spacetimedb::reducer(init)]
pub fn init(_ctx: &ReducerContext) {}The golden example: use spacetimedb::table;
#[table(name = user)]
pub struct User {
#[primary_key]
pub id: i32,
pub name: String,
pub age: i32,
pub active: bool,
}
#[table(name = product)]
pub struct Product {
#[primary_key]
pub id: i32,
pub title: String,
pub price: f32,
pub in_stock: bool,
}
#[table(name = note)]
pub struct Note {
#[primary_key]
pub id: i32,
pub body: String,
pub rating: i64,
pub pinned: bool,
}The error: Explain the difference: The generated code does not include any public fields in the struct definitions, which is a requirement for proper table mapping. Root cause: Public visibility for struct fields may not have been emphasized in the existing documentation. Recommendation: Insert and CRUD Related Testst_004_insertThe generated code: use spacetimedb::{reducer, table, ReducerContext, Table};
#[table(name = user)]
pub struct User {
#[primary_key]
id: i32,
name: String,
age: i32,
active: bool,
}
#[reducer]
pub fn insert_user(ctx: &ReducerContext, id: i32, name: String, age: i32, active: bool) {
ctx.db.user().insert(User { id, name, age, active });
}The golden example: use spacetimedb::{reducer, table, ReducerContext, Table};
#[table(name = user)]
pub struct User {
#[primary_key]
pub id: i32,
pub name: String,
pub age: i32,
pub active: bool,
}
#[reducer]
pub fn insert_user(ctx: &ReducerContext, id: i32, name: String, age: i32, active: bool) -> Result<(), String> {
ctx.db.user().insert(User { id, name, age, active });
Ok(())
}The error: Explain the difference: Missing the Root cause: Lack of emphasis on the need for public struct fields in the documentation and clear result type specifications. Recommendation: C# / docs FailuresTimeout Issuest_020_ecsThis failure is expected in both Rust and C#, highlighting a systemic timeout issue. Other Failurest_002_scheduled_tableThe generated code: using SpacetimeDB;
public static partial class Module
{
[Table(Name = "TickTimer", Scheduled = nameof(Tick), ScheduledAt = nameof(TickTimer.ScheduledAt))]
public partial struct TickTimer
{
[PrimaryKey, AutoInc] public ulong ScheduledId;
public ScheduleAt ScheduledAt;
}
[Reducer]
public static void Tick(ReducerContext ctx, TickTimer timer) { }
[Reducer(ReducerKind.Init)]
public static void Init(ReducerContext ctx)
{
var interval = new TimeDuration { Microseconds = 50_000 };
ctx.Db.TickTimer.Insert(new TickTimer
{
ScheduledAt = new ScheduleAt.Interval(interval)
});
}
}The expected example: using SpacetimeDB;
public static partial class Module
{
[Table(Name = "TickTimer", Scheduled = nameof(Tick), ScheduledAt = nameof(TickTimer.ScheduledAt))]
public partial struct TickTimer
{
[PrimaryKey, AutoInc] public ulong ScheduledId;
public ScheduleAt ScheduledAt;
}
[Reducer]
public static void Tick(ReducerContext ctx, TickTimer _row) { }
[Reducer(ReducerKind.Init)]
public static void Init(ReducerContext ctx)
{
var interval = new TimeDuration { Microseconds = 50_000 };
ctx.Db.TickTimer.Insert(new TickTimer
{
ScheduledId = 0,
ScheduledAt = new ScheduleAt.Interval(interval)
});
}
}The error: Explain the difference: In the generated code, the scheduled fields are improperly initialized, and the reducer method signatures do not entirely match expectations regarding types and method names. Root cause: Possibly unclear examples in the documentation regarding the scheduled fields and method signature conventions. Recommendation: ConclusionThe main failures across languages predominantly stem from three issues:
Specific recommendations center around enhancing documentation with clearer examples, emphasizing visibility requirements, and detailing the return types for functions. This will help streamline the development process and mitigate these common errors in future benchmarks. |
919aaca
into
2.0-breaking-changes
Merge master and fix conflicts.