Host leaves meeting, guest becomes Host? (Zoom Workplace accounts only)

API Endpoint(s) and/or Zoom API Event(s)

Description
I have a workflow in place that works without issue with vanilla Zoom accounts but has an issue when implemented on a Zoom Workplace one:

Effectively, I am leveraging Server-to-Server OAuth and the Zoom Meeting API to create and manage ad hoc meetings, making use of the create, update status (to “end”) and delete endpoints. I have a Meeting SDK based application as a client that acts as the “host”, which via my application is triggered to “leave” the meeting prior to the status and delete endpoints being invoked.

When this workflow is implemented with vanilla Zoom accounts, everything is fine. The “host” application leaves, the meeting is marked as ended, and the guest is notified that the meeting has ended, and that’s that.

However, when implementing this exact same codebase on an account that is Zoom Workplace, the “host” application leaves, and somehow the guest is made the host–which then makes things get whacky upstream. The guest isn’t even a member of the organization, and definitely isn’t listed as an alternative host, etc., in the configurations. Is there perhaps some behind-the-scenes voodoo in Workplaces to make meetings persist until the original host returns?

((Note: due to technical debt I would not be able to easily modify the workflow so that the “host” application “leave” trigger happens after the “update” and “delete” invocations; it makes for a dirtier event flow and works as-is for regular Zoom accounts; this problem is limited to Workplace accounts))

As an experiment, my team created an alternate temporary code pathway to overcome the “technical debt” I referred to earlier, and changed the invocation flow so that the change status endpoint would be invoked ahead of the Meeting SDK client being told to leave the meeting; as usual, this works fine for “vanilla” Zoom accounts, but the guest stays in the meeting when tested with a Workplace account. Please advise.