Zach Loafman

~Oh, except that error is also exactly what you expect after the container restarts, that's right. (Trying to page this all back in.)~ (ignore me, I think I'm confused.)

The health.go:256 error message _is_ present, but I think that's expected in between the update to the `Pod` and the update to the `GameServer`. This going to be a bit...

Also, this race only really exists because the game server in this case was able to call `Ready()` so quickly. Another way to close the race from the unit test...

There is a design for this in #2797 now, I propose we take further discussion there.

@valentintorikian - I see you have a commit that would fix this. Would you like to send a PR? Thanks!

@roberthbailey Saw this as a good first issue, is this stale given your previous comment?

Is this even worth pursuing? I feel like it should just be a documented limitation of the YAML install, which is less robust anyways.

`status.phase` is a synthetic view really meant for humans. As pointed out in the link: _The phase of a Pod is a simple, high-level summary of where the Pod is...

An example that I ran into of why this might happen is if the second container in the pod comes up too slowly. A game server pod typically has an...

> @roberthbailey I'm happy to fix up the documentation on mutual-exclusivity after this goes in. It looks like we could even use an approach like https://stackoverflow.com/questions/53508229/helm-chart-with-dependent-values to just ensure it.