Summary
The Beamable Unity SDK can attach version headers to its API requests, but the code that does so is compiled out unless a define symbol is set, so no shipping build sends them by default. As a result there is no server-side signal for which SDK version a client is running.
This came up during a support investigation where we tried to determine which Beamable Unity SDK version a customer's realms were on, and found no reliable request-level telemetry for it.
Current behavior (verified in-tree)
AddVersionHeaders in client/Packages/com.beamable/Runtime/Core/Platform/SDK/PlatformRequester.cs (~L557-566, called from the main request path ~L639) is doubly gated:
[Conditional("BEAMABLE_ENABLE_VERSION_HEADERS")]
protected void AddVersionHeaders(Dictionary<string, string> headers)
{
#if !BEAMABLE_DISABLE_VERSION_HEADERS
headers[HEADER_BEAMABLE_VERSION] = _beamableVersion.ToString();
headers[HEADER_APPLICATION_VERSION] = Application.version;
headers[HEADER_UNITY_VERSION] = Application.unityVersion;
headers[HEADER_ENGINE_TYPE] = $"Unity-{Application.platform}";
#endif
}BEAMABLE_ENABLE_VERSION_HEADERS is not defined in a default build, so the method is a no-op and none of these headers are sent:
X-KS-BEAM-SDK-VERSION - SDK versionX-KS-USER-AGENT - engine/platform (e.g. Unity-Android)X-KS-USER-AGENT-VERSION - Unity versionX-KS-GAME-VERSION - developer Application.version
(Header name constants: client/Packages/com.beamable/Common/Runtime/Constants/Implementations/RequesterConstants.cs.)
Expected
A default build sends the version headers, so the backend can observe which SDK version each client is running.
Proposed change
Send the version headers by default: invert the gating so they are on out of the box, and keep BEAMABLE_DISABLE_VERSION_HEADERS as the opt-out for anyone who needs to suppress them (request size, privacy).
Related
Recording these values server-side is tracked separately for the Scala stack and the C# stack (linked below). This SDK change is the prerequisite - without it there is nothing for the backend to record.
Related issues
Summary
The Beamable Unity SDK can attach version headers to its API requests, but the code that does so is compiled out unless a define symbol is set, so no shipping build sends them by default. As a result there is no server-side signal for which SDK version a client is running.
This came up during a support investigation where we tried to determine which Beamable Unity SDK version a customer's realms were on, and found no reliable request-level telemetry for it.
Current behavior (verified in-tree)
AddVersionHeadersinclient/Packages/com.beamable/Runtime/Core/Platform/SDK/PlatformRequester.cs(~L557-566, called from the main request path ~L639) is doubly gated:BEAMABLE_ENABLE_VERSION_HEADERSis not defined in a default build, so the method is a no-op and none of these headers are sent:X-KS-BEAM-SDK-VERSION- SDK versionX-KS-USER-AGENT- engine/platform (e.g.Unity-Android)X-KS-USER-AGENT-VERSION- Unity versionX-KS-GAME-VERSION- developerApplication.version(Header name constants:
client/Packages/com.beamable/Common/Runtime/Constants/Implementations/RequesterConstants.cs.)Expected
A default build sends the version headers, so the backend can observe which SDK version each client is running.
Proposed change
Send the version headers by default: invert the gating so they are on out of the box, and keep
BEAMABLE_DISABLE_VERSION_HEADERSas the opt-out for anyone who needs to suppress them (request size, privacy).Related
Recording these values server-side is tracked separately for the Scala stack and the C# stack (linked below). This SDK change is the prerequisite - without it there is nothing for the backend to record.
Related issues