ReloginTokenEvent

Answers ReloginRequest, and it is the only thing worth waiting for in that exchange.

CHECK THE FLAG BEFORE YOU READ THE TOKEN

A REFUSAL IS NOT AN ERROR MESSAGE, and it is not silence - the server answers, the flag is simply clear. Read the flag first. If you read the token unconditionally you will carry an empty string into the next connection and fail authentication there, far from the cause and looking nothing like this exchange.

THE REAL CLIENT OVERWRITES ON REFUSAL. It does not keep the token it already had: on the refusal branch it stores an empty string over it, deliberately. Do the same. A stale token from an earlier session is worse than none, because it will be presented and rejected.

WHAT THE TOKEN IS FOR

The next connection presents it instead of a full authentication round. Store it, then proceed with whatever you were doing - the real client stores it and only then replays the menu action that asked for it. If you act first and store second, you can leave the server before the value is in hand.

READ IT BY ROLE, NOT BY NUMBER

The message is padded, and the padding is different in every build - a nested message here, a spare bool there, a map somewhere else - while the two members that matter keep swapping field numbers between builds. Two members are live: one bool that says whether a token was granted, and one string that carries it. Everything else in the declaration is padding no client has ever read.

IT ARRIVES BY TYPE. The request went out uncorrelated, so nothing links this event back to it by uid. There is only ever one of these exchanges in flight, so nothing needs correlating.