GitLab

When a UI element can be updated either by loading data from the DB or in response to an event, there's the potential for a race condition that results in stale data being shown:

• DB task loads data from the DB
• DB is updated, event is broadcast
• Event handler posts an update to the UI thread
• DB task posts an update to the UI thread, overwriting changes from event

There are a lot of race conditions like this in the existing codebase when adding, removing, or updating list items.

The race can be avoided by starting a new DB task from the event handler: the DB executor is single-threaded, so the new task is guaranteed to access the DB and post its update to the UI thread after any existing tasks. But this is inefficient - where possible, it would be nice if we could use the information in the event to update the UI without hitting the DB.