Possible issue with SystemLogApi.ListLogEvents() in Okta.Sdk 10.0.3

Questions API
1

Hello,

I’m using Okta.Sdk 10.0.3 with OAuth 2.0 (private_key_jwt).

Authentication is successful:

  • UserApi.ListUsers() works.
  • Calling GET /api/v1/logs via the REST API with the same access token works.

However, when using the SDK:

var logs = systemLogApi.ListLogEvents(limit: 100);

 

var enumerator = logs.GetAsyncEnumerator();

 

while (enumerator.MoveNextAsync().AsTask().GetAwaiter().GetResult())

{

    var log = enumerator.Current;

}

the first call to MoveNextAsync() throws:

Okta.Sdk.Client.ApiException: Error calling OktaPagedCollectionEnumerator

There is no inner exception, and the issue occurs even when no since or until parameters are supplied.

Is this a known issue with SystemLogApi in version 10.0.3, or is there a recommended way to consume ListLogEvents()?

Thank you.

2

Hi,

I am able to run the provided code. Could you try to catch the exception by using below code :

 var systemLogApi = new SystemLogApi(config);

  var logs = systemLogApi.ListLogEvents(limit: 100);
  var enumerator = logs.GetAsyncEnumerator();
  
  try
  {
      while (await enumerator.MoveNextAsync())
      {
          Console.WriteLine(enumerator.Current.EventType);
      }
  }
  catch (ApiException ex)
  {
      Console.WriteLine($"ErrorCode: {ex.ErrorCode}");
      Console.WriteLine($"Message: {ex.Message}");
      Console.WriteLine($"InnerException: {ex.InnerException}");
      Console.WriteLine($"StackTrace: {ex.StackTrace}");
  }

Thanks,

Ashutosh

3

Since the raw REST call works with the same token, this smells like an SDK deserialization or pagination bug rather than auth. The generic “Error calling OktaPagedCollectionEnumerator” with no inner exception is unhelpful, worth wrapping the loop in try/catch and logging the full exception including any response body. Also check the 10.x GitHub issues, there’ve been reports of the paged enumerator choking. Might be worth testing a slightly older SDK version to isolate it.

4

Agreed, raw REST succeeding with the same token pretty much rules out auth and points straight at the SDK layer. The paged enumerator swallowing the inner exception is the frustrating part, so logging the full exception chain (and the actual HTTP response body it choked on) is the right first move, since it’s often a single record or field that doesn’t deserialize cleanly. The version-downgrade test is a smart isolation step too. If an older SDK works, you’ve confirmed a regression and can point the maintainers at the exact range. Worth checking their GitHub issues for the enumerator specifically.