Haven't looked but suspect this is simply because the parallel machinery is unaware of @runs_once and so by the time @runs_once's memoization implementation kicks in, it's already inside its own multiprocessing subprocess, and so of course the reliance on shared state for memoization to function, means it runs once per host.
Assuming that's accurate, make the parallel machinery aware of @runs_once's desired behavior, either by looking for an existing attribute, or adding a 'hint' in @runs_once's implementation and look for that.
I actually cannot replicate this now, and upon inspection, we are explicitly handling this by having @runs_once mark the decorator as serial, and have since at least 1.3.x.
@bracki I think you were the one who mentioned this on IRC; can you please confirm your instance of this bug and verify the version you're seeing it with? (And ideally how to replicate it.)
Add test to guard against #681 regressing.
Then it is a misunderstanding stemming from the documentation on runs_once. It explicitly warns that runs_once does not go along with parallel mode.
Aha, totally missed that. It was probably added before we implemented the solution I mentioned. I'll fix that posthaste, thanks!
Fix #681 by updating runs_once docstring
Switch up re #681 to be nice and not complain