Spacetimedb fails to update sender dependent view

[gmorenz]

There's some strange concurrency related issue where my view stops receiving updates when it should. I've got a reproduction here.

In short: I have a table and a view of that table that filters by identity. I have two connections to the database, both subscribed to the view. When I drop the one connection, the other connection stop updating its version of the view. This reliably happens in the reproduction - though I'm not sure I've captured all relevant portions of the reproduction in my short description of it.

Specifically with that reproduction

I expect to see, and I do see if comment out drop(_player2) on line 44

Created new database with name: testdb-918057, identity: c200ce9ae79443490f432c41870961263ba21ad9b4430888280be63cdf14341e
Decrementing from GameState { game_id: 0, player_1: Identity(c2006b4c8f707baa7d53c411b3147c34a1025ecaa5a744e01d158d8f72d51cc8), counter: 3 }
[src/main.rs:64:12] game.counter = 3
Update: GameState { game_id: 0, player_1: Identity(c2006b4c8f707baa7d53c411b3147c34a1025ecaa5a744e01d158d8f72d51cc8), counter: 2 }
Insert: GameState { game_id: 0, player_1: Identity(c2006b4c8f707baa7d53c411b3147c34a1025ecaa5a744e01d158d8f72d51cc8), counter: 2 }
Decrementing from GameState { game_id: 0, player_1: Identity(c2006b4c8f707baa7d53c411b3147c34a1025ecaa5a744e01d158d8f72d51cc8), counter: 2 }
[src/main.rs:64:12] game.counter = 2
Update: GameState { game_id: 0, player_1: Identity(c2006b4c8f707baa7d53c411b3147c34a1025ecaa5a744e01d158d8f72d51cc8), counter: 1 }
Insert: GameState { game_id: 0, player_1: Identity(c2006b4c8f707baa7d53c411b3147c34a1025ecaa5a744e01d158d8f72d51cc8), counter: 1 }
Decrementing from GameState { game_id: 0, player_1: Identity(c2006b4c8f707baa7d53c411b3147c34a1025ecaa5a744e01d158d8f72d51cc8), counter: 1 }
[src/main.rs:64:12] game.counter = 1
Update: GameState { game_id: 0, player_1: Identity(c2006b4c8f707baa7d53c411b3147c34a1025ecaa5a744e01d158d8f72d51cc8), counter: 0 }
Insert: GameState { game_id: 0, player_1: Identity(c2006b4c8f707baa7d53c411b3147c34a1025ecaa5a744e01d158d8f72d51cc8), counter: 0 }
Decrementing from GameState { game_id: 0, player_1: Identity(c2006b4c8f707baa7d53c411b3147c34a1025ecaa5a744e01d158d8f72d51cc8), counter: 0 }
[src/main.rs:64:12] game.counter = 0

And instead I see

Created new database with name: testdb-916316, identity: c200a10ca3af95f4b677415dee8c49e7ea6f5b6ce18d346d215949abfad1048f
Decrementing from GameState { game_id: 0, player_1: Identity(c2006979f28befcb0d97a7a0a0460b8f8226da108a27447f8cd587915defd27f), counter: 3 }
[src/main.rs:64:12] game.counter = 3
Update: GameState { game_id: 0, player_1: Identity(c2006979f28befcb0d97a7a0a0460b8f8226da108a27447f8cd587915defd27f), counter: 2 }
Insert: GameState { game_id: 0, player_1: Identity(c2006979f28befcb0d97a7a0a0460b8f8226da108a27447f8cd587915defd27f), counter: 2 }
Decrementing from GameState { game_id: 0, player_1: Identity(c2006979f28befcb0d97a7a0a0460b8f8226da108a27447f8cd587915defd27f), counter: 2 }
[src/main.rs:64:12] game.counter = 2
Update: GameState { game_id: 0, player_1: Identity(c2006979f28befcb0d97a7a0a0460b8f8226da108a27447f8cd587915defd27f), counter: 1 }
Decrementing from GameState { game_id: 0, player_1: Identity(c2006979f28befcb0d97a7a0a0460b8f8226da108a27447f8cd587915defd27f), counter: 2 }
[src/main.rs:64:12] game.counter = 2
Update: GameState { game_id: 0, player_1: Identity(c2006979f28befcb0d97a7a0a0460b8f8226da108a27447f8cd587915defd27f), counter: 0 }
Decrementing from GameState { game_id: 0, player_1: Identity(c2006979f28befcb0d97a7a0a0460b8f8226da108a27447f8cd587915defd27f), counter: 2 }
[src/main.rs:64:12] game.counter = 2

thread 'main' (916316) panicked at src/main.rs:66:18:
Failed to send decrement reducer: "Counter underflow"

I've tested this against both 2.0.3 and a server compiled from the latest master.

[joshua-spacetime]

Fixed by #4607

[gmorenz]

The issue still reproduces when run against a server compiled on the latest master, with no change in behavior. As explained in my comment on the PR I don't find this surprising because the reproduction uses one identity per connection.