One could usefully distinguish between a vanilla RFO and an "RFO prefetch".
An RFO prefetch would when the core sends the RFO before it is ready to commit the store to cache (generally, before the store is at the head of the store buffer: i.e., next in line). It might still send an RFO prefetch early in this case, because your scenario usually doesn't happen, and if it waited until each store was at the head of the queue before processing it, no memory level parallelism would be possible for stores. This RFO prefetch could be triggered when the the store address (STA) part of the store executes: i.e., when its address is calculated, or it could also be triggered by some component that looks at the upcoming entries in the store buffer and issues RFO prefetches for the request.
In the case of an RFO prefetch, the line could be lost before you the core is ready to commit the line, as you have described. Usually this does not happen because most lines are not heavily contented (or contended at all), but it could. It only causes a performance problem, not a forward progress one, because the core can ask for the line again.
The second type of RFO, what I call "vanilla", would occur when the store is at the head of the store queue. In this case, the store can be committed as soon as the line is received in the exclusive state, so there is "no time" for another core to interrupt the process (in practice, it may not be instantaneous, but the core back either temporarily ignore or NACK incoming requests for this line by other cores).