Best practice for deleting rows with active listeners

[nicholaschiang]

I have a Drift + Riverpod application that roughly follows the example implementation included in this repository. I have a UI where I list elements and then each of those elements has their own Riverpod provider where they fetch information about the element. The idea being that I can fetch information for each element as they are scrolled into view and don't have to load a large SQL query upfront. However, this causes issues when I go to delete one of those items in the list. The item is removed from the db but the Riverpod provider for the element complains about:

Bad state: Expected exactly one element, but got 0
#0      singleElements (package:drift/src/utils/single_transformer.dart:31:34)
#1      Selectable.watchSingle (package:drift/src/runtime/query_builder/statements/query.dart:244:30)
#2      ExerciseSetNotifier.build (package:alkeides/stores/exercise_set.dart:14:18)

...this is expected because the row has been removed, but the widget is still in the tree for a bit it seems and thus I see these error logs.

Is there a way to avoid this? What's the recommended architecture for lists of items that can be deleted (where each item in the list has its own store that it listens to for e.g. sub items)?

Edit: I'm more than happy to provide more detailed code snippets if my high-level explanation was too vague.

[cookesan]

Use the nullable single-row stream for a row that can disappear.

watchSingle() is documented as asserting that exactly one row is emitted each time the query runs, and the implementation is watch().transform(singleElements()). So the error after delete is the intended invariant failure: the query is now returning zero rows while something is still listening. watchSingleOrNull() is the variant documented for empty result sets; it emits null instead of treating the missing row as an error.

For a deletable list item provider, I would make the row-level provider return Stream<T?> from watchSingleOrNull() and treat null as "this row has been deleted" in the UI/state layer. autoDispose is still useful so off-screen rows stop listening quickly, but it does not remove the short window where the widget/provider is alive and the database has already emitted the delete.

Keep watchSingle() for places where row absence is actually a bug. For list rows that users can remove, either derive the visible row state from the parent list query or make the per-row provider nullable.

[simolus3]

I agree with watchSingleOrNull(). If you want to keep showing the last snapshot of a row before it was deleted, you could also apply a where() on the stream to ignore snapshots with no rows.

[nicholaschiang]

Thanks for the helpful responses @cookesan and @simolus3!

I also just wanted to say that I've been very impressed with this library—I migrated to PowerSync + Drift + Riverpod and it's been so fast—and how quick I've gotten response to issues/discussions. Incredible!