Do you have a specific application or scenario in mind, or is this a generic question?
I'll just answer generically: there are several layers to the system. It's expected that network deadzones will periodically result in loss of contact to robots, but RMF (specifically rmf_core) actually is talking to fleet managers, which are often provided by vendors and system integrators, and hence are "already" presumably tuned to deal with dead zones specific to a particular deployment. Presumably they would have already addressed network coverage in areas where tasks are typically completed.
RMF (through its fleet adapters) is paying attention to tasks as they evolve and replanning as necessary to avoid conflicts. In general it tries to be "hands-off" and allow the fleet managers to accomplish their tasks however the fleet manager sees fit, so long as conflicts are not in the foreseeable future. If long outages are expected and normal due to network coverage (or lack thereof) such expectations would need to be built into the fleet manager, which could provide estimated position updates back to rmf_core, even in the absence of robot comms. When the robot pops up again on the network and offers a position update, then the fleet adapter could adjust its predicted path rollout to match reality, and at that point, rmf_core could need to step in and start a negotiation if a conflict is foreseen.
