It Survives the Process — by the Least Clever Method

Through part 4 the waiting count lived like this.

var waiting = 3;

Kill the process and it is 3 again. Unplug the desk screen and the queue never happened.

Write it down

const _statePath = 'desk-state.json';

int _load() {
  final f = File(_statePath);
  if (!f.existsSync()) return 3;
  final m = jsonDecode(f.readAsStringSync()) as Map<String, dynamic>;
  return (m['waiting'] as num).toInt();
}

void _save(int waiting) =>
    File(_statePath).writeAsStringSync(jsonEncode({'waiting': waiting}));

And call it when the value changes.

waiting -= n;
_save(waiting);

Why rewrite the whole file

One value changes and the whole file is rewritten. Inefficient. But it has a property.

It never leaves a half-written record. The write either happened or it did not. Die in the middle and the old file is still there.

A partial update is not like that. Edit one record in place and die, and a file that is neither is left, and the next boot fails to parse. From there, recovery is work.

At tens of thousands of records this does not hold. That is where a database belongs. Until then, this is the safest thing there is.

Which floor

State can live on one of three floors.

Through part 4 it was the second. This piece moves it to the third.

If you do not decide, you get the second. And the day that becomes a problem is usually at night.