IPreMeetingServiceDotNetWrap.ListMeeting() claims API is uninitialized

Description
While all other services/controllers are working fine, the premeeting service returns SDKERR_UNINITIALIZE when ListMeeting() is called.

Which version?
v4.6.21666.0428

(.NET 4.7.1 WPF application using C# 8; VS2019; target x86.)

To Reproduce(If applicable)
Steps to reproduce the behavior:

  • Initialize the SDK
  • Perform user login by email address
  • Try to list meetings with the code shown below:
private async Task TryListMeetings()
{
    TaskCompletionSource<ulong[]> tcs = new TaskCompletionSource<ulong[]>();
    var wrap = CZoomSDKeDotNetWrap.Instance.GetPreMeetingServiceWrap();
    wrap.Add_CB_onListMeeting(Callback);

    var result = wrap.ListMeeting();
    // result is always SDKERR_UNINITIALIZE
    // The callback is never executed
    await tcs.Task;

    void Callback(PreMeetingAPIResult result, ulong[] meetingIds)
    {
        tcs.SetResult(meetingIds);
    }
}

Expected result:

  • result is SDKERR_SUCCESS
  • callback is called with meeting IDs

Actual result:

  • result is SDKERR_UNITIALIZE
  • callback is never executed

Additional context

Everything else in the API seems to be working (or at least nearly working; I’ve encountered a few bugs to work around, but nothing particularly nasty). I’m obtaining the PreMeetingService in exactly the same way as all the other services.

I can’t see any extra kind of initialization I need to perform, and the samples I’ve looked at don’t have anything that I can see either.

Hi jonskeet,

Thanks for using Zoom SDK and thanks for sharing your findings. May I confirm the following:

  • Since the SDK initialization and the login requests are async requests, you could only perform any other actions after you receive the success status in the callback. Are you getting this error after you were successfully initialized and logged in?

I will forward this to the engineering team for investigation. Thanks!

Yes, both SDK initialization and login have completed successfully. I’ve been able to access the display name of the signed-in user, and I can start scheduled meetings as them if I have the meeting ID already (which I can’t do without performing login first) so it looks like the login really has completed successfully.

Hi jonskeet,

Thanks for the reply. This sounds unexpected. I have forwarded this to the engineering team for further investigation. If we identified an issue, we will fix it as soon as possible.

Thanks!