Symptom: On a freshly provisioned Linux VM, downloading and running actions-runner v2.336.0 (./run.sh --jitconfig <config>) fails to register deterministically, throwing:
System.Runtime.Serialization.SerializationException: Cannot add the same member twice to a SerializationInfo object
originating from RSAFileKeyManager.GetKey(). This happens on every retry, on every fresh VM of this class we've tried.
Rolling back to v2.335.1 with an otherwise-identical JIT config registers successfully every single time on the same VM class.
Investigation so far:
- Diffed
RSAFileKeyManager.cs, IRSAKeyManager.cs, IOUtil.cs, and StringUtil.cs between v2.335.1 and v2.336.0 directly from raw.githubusercontent.com — they are byte-identical. The credential file is read via Newtonsoft.Json, not the dotnet SDK's own serialization, so a dotnet-SDK version bump between these releases doesn't explain it either.
Runner.cs does differ: v2.336.0 adds a new cleanupLocalConfigAfter404 code path that calls configManager.DeleteLocalRunnerConfig() when a spurious TaskAgentNotFoundException/RunnerNotFoundException occurs during message polling. This path does not exist at all in v2.335.1.RSAFileKeyManager.GetKey() is invoked on every OAuth token exchange (OAuthCredential.cs, MessageListener.CreateSessionAsync) throughout the runner's lifetime, not just once at startup.- Leading hypothesis (not confirmed via live repro): the new cleanup path racing a concurrent
GetKey() read/write of the same on-disk credential file is causing the SerializationException. This would explain why it's version-specific and deterministic specifically in a fresh-VM, JIT-registration-per-job flow (as opposed to a long-lived runner registering once).
Environment: ephemeral Linux VM, fresh runner binary downloaded per job, JIT registration via --jitconfig. No newer release than v2.336.0 existed as of this investigation.
Question: has this been seen elsewhere, and is there a fix planned or already shipped past v2.336.0?
Symptom: On a freshly provisioned Linux VM, downloading and running actions-runner v2.336.0 (
./run.sh --jitconfig <config>) fails to register deterministically, throwing:originating from
RSAFileKeyManager.GetKey(). This happens on every retry, on every fresh VM of this class we've tried.Rolling back to v2.335.1 with an otherwise-identical JIT config registers successfully every single time on the same VM class.
Investigation so far:
RSAFileKeyManager.cs,IRSAKeyManager.cs,IOUtil.cs, andStringUtil.csbetween v2.335.1 and v2.336.0 directly fromraw.githubusercontent.com— they are byte-identical. The credential file is read via Newtonsoft.Json, not the dotnet SDK's own serialization, so a dotnet-SDK version bump between these releases doesn't explain it either.Runner.csdoes differ: v2.336.0 adds a newcleanupLocalConfigAfter404code path that callsconfigManager.DeleteLocalRunnerConfig()when a spuriousTaskAgentNotFoundException/RunnerNotFoundExceptionoccurs during message polling. This path does not exist at all in v2.335.1.RSAFileKeyManager.GetKey()is invoked on every OAuth token exchange (OAuthCredential.cs,MessageListener.CreateSessionAsync) throughout the runner's lifetime, not just once at startup.GetKey()read/write of the same on-disk credential file is causing theSerializationException. This would explain why it's version-specific and deterministic specifically in a fresh-VM, JIT-registration-per-job flow (as opposed to a long-lived runner registering once).Environment: ephemeral Linux VM, fresh runner binary downloaded per job, JIT registration via
--jitconfig. No newer release than v2.336.0 existed as of this investigation.Question: has this been seen elsewhere, and is there a fix planned or already shipped past v2.336.0?