[Crash] Assertion 'current != nullptr' failed | SDK is not active

[normal88]

Summary

Server crashes with a fatal assertion in the citizen-scripting core module.

Issue type

Server

Repro rate

Always

Server build version

FXServer-early-access b92 win32

OS

Windows 11 25H2

CPU

AMD Ryzen 5 8400F

GPU

NIVIDA RTX 4060

RAM

32GB DDR5

Storage type

SSD NVMe

Connection type

Ethernet

ISP and bandwidth

100 Mbps

DxDiag

No response

Network graph

No response

Platform

Windows

OS version / distribution

Windows Server 2022

CPU

AMD EPYC 7402P 24-Core

RAM

24 GB

Using txAdmin?

No

Hosting provider

Cloud provider (AWS, GCP, Azure, etc.)

Machine type

VPS

/perf endpoint output

Unauthorized.

DDoS protection

Yes, Cloudflare

ulimit -n value (Linux only)

No response

Docker Compose file (Docker only)

No response

Steps to Reproduce

1.Run two chat resources simultaneously on the server (in this case: default chat resource + external Chat).
2.Open chat and type a message in the first (original) chat resource, then send it.
3.Before closing, the second chat resource's UI is still open/focused.
4.Type a message in the second chat UI and send it.
5.Server immediately throws a Fatal Error dialog: Assertion Failure! 'current != nullptr' failed | SDK is not active.
6.Pressing OK on the dialog crashes/kills the server process.

Expected Behavior

Having two chat resources active and receiving input shouldn't cause a fatal engine-level assertion. At worst, this should be handled as a resource-level error (e.g., one resource logs a warning or fails gracefully) — it should never crash the entire server process. The scripting SDK/runtime context should remain stable even when multiple resources are competing for chat input focus at the same time.

Actual Behavior

Instead of failing gracefully, the server throws a fatal engine-level assertion — Assertion Failure! 'current != nullptr' failed | SDK is not active — and crashes the entire FXServer process when the "OK" button on the error dialog is pressed. This takes down the whole server for all connected players, rather than being isolated to the misbehaving resource(s).

Evidence

No response

Additional Context

No response

[Rodhin]

Are you sure it's caused by having two chat resources? I think it's related to the latent events, when I try to trigger a latent server event from client side (in nodejs) I get this same SDK assertion error. Can you check if either of those chat resources is using latent events?

[Gogsi]

Hey can you provide a simple reproduction for the latent server event crash

[Gogsi]

Ok nevermind, we have confirmed latent events from Node cause this crash. Thanks for the info!

[Gogsi]

A fix for this bug has been implemented and is available in the latest patch. Please try again and let us know if the issue persists. Thanks for your help!

[normal88]

Thanks for the fix! Can confirm it's working now — I updated to the latest patch and tested with the same setup (two chat resources + latent events), and the crash no longer happens. Appreciate the quick turnaround on this.