This means that we will stop the upload when the app becomes backgrounded. I'm wondering whether in the future we will need to change this approach. It's possible, that uploading the whole backup could take a long time, and it's possible that a user won't keep the app foregrounded long enough. We will probably need a resumable approach, or to find a way of continuing while backgrounded.

This could be scary to see in the logs. If it doesn't indicate a serious issue, we should make this log less scary, e.g. Local device list state wasn't updated yet - updating it now. If it is a real problem, maybe we should also explain that Local device list state is inconsistent - this shouldn't happen and needs to be investigated!

This is an interesting pattern! We can consider creating a logger utility, that is instantiated at the beginning of a procedure, then its status is updated though the execution, and every log it prints is prefixed by the step identifier. Just an idea for the future.

I'm not sure, but maybe it could be less confusing to set it to false in the effect just before calling process.

Why are we using staffCanSee here? Should we also use usingRestoreFlow somehow?

Should rerun be used in this effect? What's the meaning of it? Shouldn't we process only after it is set to true and then set to false when appropriate?

If we don't care about its value, but only about the value change, maybe a less confusing approach could be to replace it with an iteration counter and increment it at the end of the processing.

I like this idea!