This post[1] talks about the mechanics of implementing this netcode. The scenario you're talking about would be a "desync," where in your simulation, the opponent never saw you, but in the opponent's sim, they did. You really don't want that, as that quickly makes the game diverge and become unplayable.
What most games that use this technique do is "lockstep" - they send out a chunk of commands called a "frame" several times a second, and step the simulation forward to step n only when they have frame n from every player.
So, in your scenario, if player A cancels before troops are visible to player B, then player B's computer won't ever show the troops, because simulation B will have paused during the 500ms of network lag, since it didn't have the frame from player A.
It’s worth noting that often lockstep is not appropriate. Fighting games, for instance, require frame-perfect inputs. Fighting games become hard to play perfectly if you introduce jitter into the timing by requiring frame synchronization. In a fighting you’d just unwind whatever happened and replay the simulation as if the “real” thing happened, which could mean undoing things a user saw in certain circumstances.
Many fighting games did and do use lockstep; it’s only recently that rollback has started to become the norm, and some recent big releases still don’t have it. But fans actively clamor for rollback because it’s a far superior experience.
What most games that use this technique do is "lockstep" - they send out a chunk of commands called a "frame" several times a second, and step the simulation forward to step n only when they have frame n from every player.
So, in your scenario, if player A cancels before troops are visible to player B, then player B's computer won't ever show the troops, because simulation B will have paused during the 500ms of network lag, since it didn't have the frame from player A.
[1] https://news.ycombinator.com/item?id=34395153