Skip to main content

GitHub Copilot SDK issue after upgrading to the 1.0.0-beta.10

After upgrading the GitHub Copilot SDK to the 1.0.0-beta.10 version, initiating the CopilotClient no longer worked. Instead I got the following error message: 

System.Text.Json.JsonException: The JSON value could not be converted to System.DateTimeOffset. Path: $.timestamp | LineNumber: 0 | BytePositionInLine: 43.  ---> System.InvalidOperationException: Cannot get the value of a token type 'Number' as a string.    at System.Text.Json.ThrowHelper.ThrowInvalidOperationException_ExpectedString(JsonTokenType tokenType)    at System.Text.Json.Utf8JsonReader.TryGetDateTimeOffset(DateTimeOffset& value)    at System.Text.Json.Utf8JsonReader.GetDateTimeOffset()    at System.Text.Json.Serialization.Converters.DateTimeOffsetConverter.Read(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options)    at System.Text.Json.Serialization.Metadata.JsonPropertyInfo`1.ReadJsonAndSetMember(Object obj, ReadStack& state, Utf8JsonReader& reader)    at System.Text.Json.Serialization.Converters.ObjectDefaultConverter`1.OnTryRead(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options, ReadStack& state, T& value)    at System.Text.Json.Serialization.Converters.JsonMetadataServicesConverter`1.OnTryRead(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options, ReadStack& state, T& value)    at System.Text.Json.Serialization.JsonConverter`1.TryRead(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options, ReadStack& state, T& value, Boolean& isPopulatedValue)    at System.Text.Json.Serialization.JsonConverter`1.ReadCore(Utf8JsonReader& reader, T& value, JsonSerializerOptions options, ReadStack& state)    --- End of inner exception stack trace ---    at System.Text.Json.ThrowHelper.ReThrowWithPath(ReadStack& state, Utf8JsonReader& reader, Exception ex)    at System.Text.Json.Serialization.JsonConverter`1.ReadCore(Utf8JsonReader& reader, T& value, JsonSerializerOptions options, ReadStack& state)    at System.Text.Json.Serialization.Metadata.JsonTypeInfo`1.Deserialize(Utf8JsonReader& reader, ReadStack& state)    at System.Text.Json.Serialization.Metadata.JsonTypeInfo`1.DeserializeAsObject(Utf8JsonReader& reader, ReadStack& state)    at System.Text.Json.JsonSerializer.ReadFromSpanAsObject(ReadOnlySpan`1 utf8Json, JsonTypeInfo jsonTypeInfo, Nullable`1 actualByteCount)    at System.Text.Json.JsonSerializer.Deserialize(JsonElement element, JsonTypeInfo jsonTypeInfo)    at GitHub.Copilot.JsonRpc.InvokeAsync[T](String method, Object[] args, CancellationToken cancellationToken, Action`1 onResponseInline)    at GitHub.Copilot.JsonRpc.InvokeAsync[T](String method, Object[] args, CancellationToken cancellationToken, Action`1 onResponseInline)    at GitHub.Copilot.CopilotClient.InvokeRpcAsync[T](JsonRpc rpc, String method, Object[] args, StringBuilder stderrBuffer, CancellationToken cancellationToken, Action`1 onResponseInline)    at GitHub.Copilot.CopilotClient.VerifyProtocolVersionAsync(Connection connection, CancellationToken cancellationToken)    at GitHub.Copilot.CopilotClient.g__StartCoreAsync|24_0(CancellationToken ct)    at GitHub.Copilot.CopilotClient.g__StartCoreAsync|24_0(CancellationToken ct)    at GitHub.Copilot.CopilotClient.CreateSessionAsync(SessionConfig config, CancellationToken cancellationToken)    at PowerPilot.Agents.ChatAgentService.GetOrCreateSessionAsync(CancellationToken ct) in D:\Projects\PowerPilot\src\PowerPilot.Agents\ChatAgentService.cs:line 161    at PowerPilot.Agents.ChatAgentService.ChatAsync(String userMessage, CancellationToken cancellationToken)+MoveNext() in D:\Projects\PowerPilot\src\PowerPilot.Agents\ChatAgentService.cs:line 85

I was using the default CopilotClient object which uses the included Copilot CLI and spawns it up as a child process.

The workaround

My first solution was more a workaround. I changed the code to use an already running Copilot CLI instance that was using the headless mode:

copilot --headless

I updated the CopilotClient to use this instance:

    var clientOptions = new CopilotClientOptions();
    if (!string.IsNullOrEmpty(options.CliUrl))
    {
          clientOptions.Connection = RuntimeConnection.ForUri(options.CliUrl);
    }
    return new CopilotClient(clientOptions);

When making this stitch, the error disappeared at least my application was working again. Of course, this is not a final solution. But this gives us a clue that the problem is probably related with the integrated Copilot CLI.

The solution

We accidently found a solution by upgrading our application to .NET 10. At the moment we encountered the error, the app was still using .NET 8. But after doing the upgrade, the issue disappeared.

Could it be that their was a problem with the .NET 8 version of the latest SDK?

I created a minimal example to reproduce the issue. However when I ran the .NET 8 version of this minimal example, it just worked.

Than I noticed the following in the output:

1>------ Build started: Project: CopilotSDKIssueNET810, Configuration: Debug Any CPU ------
1>C:\Program Files\dotnet\sdk\10.0.300-preview.0.26177.108\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(383,5): message NETSDK1057: You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
1>  Downloading Copilot CLI 1.0.56-1 for win32-x64...
1>  Downloading from "https://registry.npmjs.org/@github/copilot-win32-x64/-/copilot-win32-x64-1.0.56-1.tgz" to "D:\Projects\Test\CopilotSDKIssueNET810\CopilotSDKIssueNET810\obj\Debug\net8.0\copilot-cli\1.0.56-1\win32-x64\copilot.tgz" (84859620 bytes).
1>  Skipping analyzers to speed up the build. You can execute 'Build' or 'Rebuild' command to run analyzers.

Aha! When updating the Copilot SDK package to the latest beta version, I assume it didn't update the corresponding CLI version. So that could be a valid reason.

As it is working now, I decided to leave it there. If the issue reappears, I’ll update this post.

Case closed…

Labels:

Popular posts from this blog

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...
Read more

Cache stampede: when our cache turned against us

While investigating some performance issues, we ran into an ASP.NET Core API that cached a fairly expensive aggregation query for 60 seconds. Under normal load, that was fine: one request rebuilds the cache, everyone else reads from it. Under peak load, dozens of requests would arrive in that same expiry window, all see a cache miss, and all fire the same expensive query in parallel. The database didn't like that. That was the moment when our caching layer stopped helping and started hurting. A burst of requests comes in at the same time, all miss the cache, and all go hammer the database or the downstream API at once. That's a cache stampede . The cache was supposed to protect our backend, and for a few hundred milliseconds it did the opposite. Why this happens IMemoryCache.GetOrCreate (and its async sibling) looks like it protects you, but it doesn't add any locking on its own. Look at the naive version: public async Task<Report> GetReportAsync(string key) ...
Read more

A complex system designed from scratch never works

A few years ago, I worked as an architect on a big mainframe rewrite. I still count it as one of my failures. Not because the technology was wrong, but because I couldn't convince the management team to simplify the approach. Years later, the organization is still struggling to get the new system up and running. I left the project at the time, because I couldn't put my name behind an approach that would take very long and cost a lot of money without a working system to show for it along the way. Gall’s Law That memory keeps coming back to me, because it's a textbook case of Gall's Law playing out in real life. Gall's Law , from John Gall's Systemantics , states it plainly: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works, and it cannot be patched to make it work. You have to start over with a simple system that works. What does that mean in practice,...
Read more