-
Notifications
You must be signed in to change notification settings - Fork 177
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
Timer Table Implementation #1449
Conversation
c0db594
to
b13cf7c
Compare
@@ -485,6 +485,7 @@ pub struct TableSchema { | |||
pub sequences: Vec<SequenceSchema>, | |||
pub table_type: StTableType, | |||
pub table_access: StAccess, | |||
pub scheduled: Option<Box<str>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the PR #1448 I'm rewriting Def. My plan was to add:
struct ScheduleDef {
reducer_name: Box<str>,
at_column: ColId
}
And then having an Option<ScheduleDef>
on TableDef
.
If you don't mind restructuring this that way it would make it easier for me down the line.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you translate this in TableSchema
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess just assert that at_column
is named "at"
and convert the reducer name.
This can be changed later once TableSchema
is updated.
.map(|row| -> Result<_> { | ||
let row = StScheduledRow::try_from(row)?; | ||
Ok(row.reducer_name) | ||
}) | ||
.transpose()?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.map(|row| -> Result<_> { | |
let row = StScheduledRow::try_from(row)?; | |
Ok(row.reducer_name) | |
}) | |
.transpose()?; | |
.and_then(|row| StScheduledRow::try_from(row).map(|r| r.reducer_name))? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ummm, scheduled
is supposed to be an Option
enum, provided suggestion does not looks to evaluates to that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that @Centril did not provide more context I would mark this as resolved.
77d405b
to
e951eb7
Compare
72bab7c
to
15bf757
Compare
15bf757
to
85a0aed
Compare
87f7dc6
to
1b3bbe0
Compare
crates/core/src/host/scheduler.rs
Outdated
// can this be shared with bindings? | ||
const SCHEDULED_AT_FIELD: &str = "scheduled_at"; | ||
const SCHEDULED_ID_FIELD: &str = "scheduled_id"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, you can move them to spacetimedb_primitives
, e.g., scheduling.rs
.
crates/core/src/host/scheduler.rs
Outdated
|
||
#[derive(Copy, Clone, Eq, PartialEq, Hash)] | ||
pub struct ScheduledReducerId(pub u64); | ||
pub struct ScheduledReducerId { | ||
/// Scheduled Table id, this should have a entry in `ST_SCHEDULED` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Shubham8287 This hasn't been addressed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good overall.
I'll want to do the manual testing before approving.
crates/core/src/host/scheduler.rs
Outdated
db.delete(tx, id.table_id, [schedule_row_ptr]); | ||
Ok::<(), anyhow::Error>(()) | ||
}) | ||
.map_err(|e| log::error!("deleting scheduled reducer failed: {e:#}")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Strangely, the types are lying -- this transaction cannot actually fail.
But if it could, we might run the scheduler again in the future, is that correct?
I think it's important to note both in the proposal and user-facing documentation that scheduled reducers have "at least once" semantics.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But does that also means that there is a bug in our logic?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it means that, like in many instances in the codebase, we formulate types not to express what is the case, but what might be the case in the future.
In this case: transactions may become fallible under MVCC, if and when that is supported, but they are, in fact, not.
If we resist debating the code structure, the possibility of this particular transaction being fallible means that we may run the scheduled reducer more than once.
I think that’s fine, but we need to be diligent in documenting the behavior.
92fff9f
to
9f5c008
Compare
b1c2b45
to
be97bda
Compare
crates/core/src/host/scheduler.rs
Outdated
Ok(schedule_row) => schedule_row, | ||
// if the row is not found, it means the schedule is cancelled by the user | ||
Err(_) => { | ||
log::info!( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we downgrade this to debug?
I created a reducer with ScheduleAt::Interval(duration!(100ms))
, and then delete the the table in the first call. That yields 3x, supposedly because it was put on the queue this many times already.
It's not immediately clear what the message is trying to tell me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you put it inside init
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So it was extra noisy for you due to bug specific for this particular case - https://discord.com/channels/931210784011321394/1011381307965722774/1257812281564073996, but I think message can still be downgraded to Debug, purpose for it is for debugging only.
20bc515
to
47dedc6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the test suite is failing for trivial reasons; with that fixed, this look good!
Update test snapshot Add support for the new timer tables Remove old scheduler ABI & API Add implicit conversions for ScheduleAt
6c2b51f
to
c9b9699
Compare
c9b9699
to
7516f72
Compare
new commits after last update are
|
Description of Changes
Host side implementation of scheduled tables as per proposal - https://github.com/clockworklabs/SpacetimeDBPrivate/blob/master/proposals/0005-timers.md
API and ABI breaking changes
yes
Expected complexity level and risk
3
Testing
Tested via running through example apps.