Unreal SDK listener lifetime after Disconnect / SetConvaiClientListner

Integrations Unreal Engine Plugin
1

What do you need help with?

Question

Installation method

FAB

Issue area

Connection / WebRTC

Impact

Blocker - I cannot continue

Unreal Engine version

5.3.2 (Unreal Engine 5.3)

Convai Unreal Engine Plugin version

4.0.0-beta.24

Project setup

Blueprint and C++

Target platform

Unreal Editor

Where does it happen?

Not tested yet

Short summary

Source-inspection question: supported native listener/client lifetime boundary after disconnect and immediate reconnect. No runtime crash reproduced.

What happened?

We are using Unreal Engine 5.3.2 and ConvAI 4.0.0-beta.24 on Windows. The plugin is installed under the engine Marketplace plugins directory; the original installation method has not been confirmed.

This concern was discovered through source-code inspection, not through a reproducible runtime crash. In the inspected Unreal wrapper, the native client registers UConvaiSubsystem as its listener. Disconnect handling queues game-thread work that captures the shared subsystem and later accesses its current session/client. This raises a possible A-to-B stale-callback/cleanup concern during immediate replacement; we have not reproduced that ordering at runtime.

The supplied native SDK header exposes SetConvaiClientListner(IConvaiClientListner*), Disconnect(), and the ConvaiClient destructor, but we could not establish a documented callback-drain/lifetime guarantee from the available header.

Could Convai engineering clarify:

  1. Can callbacks occur on the old listener after SetConvaiClientListner(nullptr)?
  2. Can callbacks occur after Disconnect() returns?
  3. Can callbacks already in flight still enter the listener?
  4. Is there an API or synchronization point that guarantees callbacks have drained?
  5. At what point is it safe to destroy the listener and ConvaiClient, and what teardown order/thread is supported?
  6. Has this lifecycle behavior been addressed or documented in a newer Convai SDK/plugin?

We paused integration rather than assume callback quiescence or rely on a fixed delay.

What did you expect?

After ending connection A, there should be a documented safe point at which A’s listener and ConvaiClient can be destroyed and connection B can start without callbacks or cleanup from A affecting B. Please clarify the supported unregister/disconnect/drain/destruction sequence.

Steps to reproduce

Source-inspection scenario for engineering review, not confirmed runtime reproduction:

  1. Start connection/session A.
  2. End/disconnect A.
  3. Immediately start connection/session B.
  4. Queued/native callbacks originating from A may execute after B becomes current.
  5. We need to know the supported lifetime boundary for A’s IConvaiClientListner and ConvaiClient.

We have deliberately not attempted to induce a crash.

Unreal logs or error messages

No runtime error logs are available: this was identified during source inspection, and we deliberately did not attempt to induce a crash.

The existing Unreal wrapper in ConvaiSubsystem.cpp delays destruction of recently disconnected clients using a background task and a two-second sleep. Its comments discuss internal WebRTC threads still shutting down. That existing delay prompted our listener-lifetime question; it is not evidence that we reproduced a crash or that a fixed delay guarantees callbacks have drained.

No credentials, proprietary project source, private character data, or conversation logs are attached.

I checked the relevant documentation, resources, and similar forum posts before posting.

on

I confirm that I did not include API keys, tokens, passwords, secrets, private character data, private conversation logs, or customer data.

on

2

Could you please clarify your exact use case and what you are trying to achieve with this connection lifecycle?

3

Sure. Our use case is an Unreal application that may run multiple AI conversation sessions sequentially without restarting the application.

The lifecycle is essentially:

Start connection A → exchange messages → End A → Start connection B

Connection B may be started shortly after A is ended.

We need to ensure that once A has been terminated, callbacks or deferred cleanup originating from A cannot affect B, and that we can safely release A’s ConvaiClient and IConvaiClientListner.

During our review of the Unreal plugin source, we noticed that destruction of a recently disconnected client is deferred, so we weren’t sure what the intended safe lifetime boundary is.

Specifically, we’re trying to determine the supported way to know when the old listener/client can safely be released before or while starting a new session.

If Convai already has a recommended lifecycle/API for handling sequential conversation sessions like this, we’d be happy to follow that approach.