[CRITICAL] Views recomputation can roll back transactions.

[kistz]

I experienced a bug where the view could not be recomputed and it causing it to propagate the error to the reducer which called it.

This panic is also not in the logs of the databse so it just siltently rolls back the data. (Internal Server Error is returned for reducers i dont know if it times out a computation limit or something )

Sadly i lost quite a bit of mission critical stuff in that incident because this reducer is built to always archive it and never panic :(

Read only data should not be able to impact a successfully commiting transaction!

I will ping @cloutiertyler and @joshua-spacetime because i think this is a very severe bug hope yall understand :>

If you have further questions pls reply or ping (also possible on discord) but i will go to sleep for now because it has been stressful figuring out the bug

[cloutiertyler]

@kistz I'm very sorry you ran into this issue. Could you please post an example of what caused the issue in the view? Was this a panic inside the code? Any more context would be greatly helpful.

It sounds like this is not necessarily a bug, but a consequence of the design, although something we might have to revisit if it's causing issues like this.

[kistz]

@cloutiertyler yes i can provide more context (sry i was still in a mental breakdown when i wrote this LOL)

So when i call a reducer this is the thing i get back on the client (so the reducer that changed a dependency of the view was successful but the recomputation fails so it propagates the error to the calling client and rolls back the commit) (happened with another view aswell)

I also never seen this before so eventually a issue with stdb 2.2 host? (but idk)

This is one of the view (but also happened with a procedural one so not a query builder issue).
As you can see its also not a issue with panicing in my code.

#[view(accessor=unstable_match_round,public)]
fn unstable_match_round(
    ctx: &AnonymousViewContext,
) -> impl Query<MatchRoundPlayer> {
    ctx.from.tab_match_round_player()
}

One thing i have to say is that i updated the db with and without a breaking change tho 🤔
maybe it hung itself because of that and then proceded to fail....

I think for the query builder view i actually did break the type (adding a default annotation)
but for the procedural one i definetly did not change a thing. (so it should not have anything to do with that)

Most likely in my head is that it borked itself on a db update?

databse on maincloud is tmservers in case the host threw some logs? Let me know if i can help with anything else

[xDovos]

this isn't a new thing. i noted this as it came out and got the answer that it is intented behaviour #3794
tho in my case it was a bad .unwrap() and not what kistz has as example

[kistz]

Well the panic is not in my code does not get logged and appeared out of nowhere when updating the database without even changing the view in that update...
So of this is imtended i am very surprised

[kistz]

I am pretty sure this is the culprit (this plus 10 lines):

SpacetimeDB/crates/core/src/host/wasm_common/module_host_actor.rs

Line 1253 in 06fa5e3

None => stdb.materialize_anonymous_view(&mut tx, table_id, rows),

it is the same error i am getting but i do not know where exactly it is failing because the real error gets swallowed by the db and turned into Error materializing view.

Both views i experienced the issue with could have started to be broken in a breaking change but i am not exactly sure about that.

Hope this helps

[kistz]

I have to correct myself after checking again: both views that broke were:

1. Anonymous
2. Query Builder views