[Bug] SetHttpHandler handler never runs in C#: SDK fails to deserialize the request object (msgpack ext 0x0b), client gets HTTP 200 with empty body

[Muulfz]

Summary

In a C# (.NET 10) server resource, a handler registered through SetHttpHandler is never actually invoked: the SDK fails to deserialize the request object the server hands to the function reference, because the request map contains callback references serialized as MessagePack extension type 0x0b, which PrimitiveObjectFormatter does not support. The exception is only visible in the server console; the HTTP client still receives HTTP 200 with an empty body, so from the outside the request looks like it succeeded. This makes inbound HTTP (webhooks, long-polling, REST-style endpoints) unusable from C# resources. An equivalent Lua resource on the same server build serves the same route correctly.

Issue type

Server

Repro rate

Always

Server build version

b106 (version command and info.json both report FXServer-early-access b106 win32; there is no numeric build id on this early-access artifact). Also reproduced on b105. SDK: CitizenFX.FiveM.Server / CitizenFX.FiveM.Shared 0.0.3-alpha.

Server details

Platform

Windows

OS version / distribution

Windows 11 Pro 25H2 (build 26200)

CPU

AMD Ryzen 9 9950X (16c/32t)

RAM

128 GB DDR5-4800

Using txAdmin?

No

Hosting provider

Self-hosted

Machine type

Dedicated

DDoS protection

No

Reproduction

Steps to Reproduce

1. Build the following single-file C# (.NET 10) server resource against CitizenFX.FiveM.Server / CitizenFX.FiveM.Shared 0.0.3-alpha (output as HttpProbe.Server.net.dll):

using System;
using CitizenFX.Base;
using CitizenFX.FiveM.Server;
using CitizenFX.FiveM.Shared;
using CitizenFX.FiveM.Shared.Script;

public sealed class HttpProbeScript : IScript
{
    public void Initialize()
    {
        // Note: there is no public HTTP wrapper in CitizenFX.FiveM.Server 0.0.3-alpha,
        // and Native.SetHttpHandler takes a raw function-reference id, so registration
        // has to go through the internal FuncRefManager (emits warning FIVEM001).
        uint refId = ((SharedCore)API.GetCore())
            .FuncRefManager.Register(new Action<object, object>(Handle));
        Native.SetHttpHandler((int)refId);
        API.Log.Info("[HTTPH] SetHttpHandler OK");
    }

    private static void Handle(object req, object res)
    {
        // Never reached: deserialization of 'req' throws before the handler runs.
        API.Log.Info("[HTTPH] HIT");
    }
}

fxmanifest.lua:

fx_version 'cerulean'
game 'gta5'

files { 'CitizenFX.FiveM.Server.dll', 'CitizenFX.FiveM.Shared.dll' }
server_script 'HttpProbe.Server.net.dll'

2. ensure the resource; the console logs [HTTPH] SetHttpHandler OK.
3. From any HTTP client: curl -i http://127.0.0.1:<port>/<resource-name>/ping
4. Watch the server console and the HTTP response.

The same failure occurs with a typed signature Action<Dictionary<string, object>, Dictionary<string, object>> — only the target type name in the exception changes.

Expected Behavior

The handler runs and receives a usable request object (headers, method, address, path, plus callable setDataHandler / setCancelHandler references), analogous to what Lua and JS handlers receive from the same SetHttpHandler native. Failing that, the HTTP client should at least receive an error status — not a 200.

Actual Behavior

• The handler body never executes. Every request logs Failed to invoke function reference ...: InvalidWrappedCallArgException in the server console (full trace below).
• The HTTP client receives HTTP 200 with an empty body for every request, so the failure is invisible to the caller.
• Reproduced 2/2 on vanilla b105 and b106 with SDK 0.0.3-alpha; every request fails identically.
• Control: a Lua resource registering SetHttpHandler on the same server build serves the same route normally (200 with the expected body), so the server side of the pipeline appears fine — the failure is in the C# SDK's argument deserialization.

Evidence

Server console output on b106 (identical on every request; Action<object, object> variant):

[18:08:18] [error] [stinx_httph_prob] Failed to invoke function reference 1: CitizenFX.FiveM.Shared.Exceptions.InvalidWrappedCallArgException: Failed to deserialize argument 'req' (index 0) to type Object. Provided value: {"headers":{"Host":"127.0.0.1:30231","User-Agent":"Mozilla/5.0 (Windows NT 10.0; Microsoft Windows 10.0.26200; en-US) PowerShell/7.6.3","Accept-Encoding":"gzip, deflate, br"},"method":"GET","address":"127.0.0.1","path":"/ping","setDataHandler":[11,"NQ=="],"setCancelHandler":[11,"NA=="]}. Extension type code 0x0b is not supported by the PrimitiveObjectFormatter.
 ---> MessagePack.MessagePackSerializationException: Failed to deserialize System.Object value.
 ---> MessagePack.MessagePackSerializationException: Extension type code 0x0b is not supported by the PrimitiveObjectFormatter.
   at MessagePack.Formatters.PrimitiveObjectFormatter.Deserialize(MessagePackReader& reader, MessagePackSerializerOptions options)
   at MessagePack.Formatters.PrimitiveObjectFormatter.DeserializeMap(MessagePackReader& reader, Int32 length, MessagePackSerializerOptions options)
   at MessagePack.Formatters.PrimitiveObjectFormatter.Deserialize(MessagePackReader& reader, MessagePackSerializerOptions options)
   at MessagePack.MessagePackSerializer.Deserialize[T](MessagePackReader& reader, MessagePackSerializerOptions options)
   --- End of inner exception stack trace ---
   at MessagePack.MessagePackSerializer.Deserialize[T](MessagePackReader& reader, MessagePackSerializerOptions options)
   at MessagePack.MessagePackSerializer.Deserialize[T](ReadOnlySequence`1& byteSequence, MessagePackSerializerOptions options, CancellationToken cancellationToken)
   at CitizenFX.FiveM.Shared.Serialization.CallParams.CallArg.Get[T](Boolean nullable, String paramName)
   --- End of inner exception stack trace ---
   at CitizenFX.FiveM.Shared.Serialization.CallParams.CallArg.Get[T](Boolean nullable, String paramName)
   at System.RuntimeMethodHandle.InvokeMethod(ObjectHandleOnStack target, Void** arguments, ObjectHandleOnStack sig, BOOL isConstructor, ObjectHandleOnStack result)
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
   at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args)
   at System.Reflection.MethodBaseInvoker.InvokeDirectByRefWithFewArgs(Object obj, Span`1 copyOfArgs, BindingFlags invokeAttr)
--- End of stack trace from previous location ---
   at System.Linq.Expressions.Interpreter.ByRefMethodInfoCallInstruction.Run(InterpretedFrame frame)
   at System.Linq.Expressions.Interpreter.Interpreter.Run(InterpretedFrame frame)
   at System.Linq.Expressions.Interpreter.LightLambda.Run(Object[] arguments)
   at Thunk2ret_Object_CallParams&(Func`2, CallParams&)
   at CitizenFX.FiveM.Shared.FuncRef.FunctionReferenceManager.InvokeOwned(UInt32 refId, ReadOnlyMemory`1 args)

Note the "setDataHandler":[11,"NQ=="] / "setCancelHandler":[11,"NA=="] entries in the logged request map — these are the msgpack extension (type 0x0b) callback references that PrimitiveObjectFormatter rejects. The request shape matches citizen-server-impl/src/ResourceHttpHandler.cpp (map of headers, method, address, path, setDataHandler, setCancelHandler, where the two handlers and the response's write/writeHead/send are callback refs).

Client side for the same request: HTTP/1.1 200 OK with Content-Length: 0.

Additional Context

• Partial workaround, which also narrows the cause: declaring the handler as Action<Dictionary<string, MessagePackBuffer>, Dictionary<string, FunctionReference>> deserializes successfully, and calling res["writeHead"] / res["send"] produces a correct HTTP response (verified on the same builds, including reading the POST body via setDataHandler). So FunctionReferenceFormatter handles the callback-ref extension types fine; the failure is specific to the untyped path where PrimitiveObjectFormatter encounters ext code 0x0b inside object / Dictionary<string, object> values. Teaching the SDK's primitive-object path to materialize callback-ref extensions as callable references (like Lua/JS do) would fix the general case.
• Silent-success masking: because ResourceHttpHandler still completes the response after the script-side failure, the caller sees 200/empty rather than a 5xx, which makes this hard to detect from monitoring.
• SDK ergonomics: there is currently no public API to register an HTTP handler from C# — Native.SetHttpHandler takes a raw funcref id, FunctionReference's constructor is internal, and registering via FuncRefManager emits warning FIVEM001 (internal-use API). A supported wrapper would make this path testable end to end.
• Server console had no other errors related to the resource; the resource loads and logs SetHttpHandler OK before the first request arrives.

[TomGrobbe]

Same thing happens on the client, so it's not only SetHttpHandler.

A raw NUI callback gets invoked with (request, responseCallback). The request map deserializes
fine, but the response callback is ext 0x0b and the whole call dies on it:

Failed to deserialize argument 'respond' (index 1) to type Object. Provided value: [11,"MTg0"].
Extension type code 0x0b is not supported by the PrimitiveObjectFormatter.

In case anyone needs a workaround for now: only declare the parameters you actually read. The binder
stops at the last parameter you declare, so a handler that only takes the request works. You can't
send a response back that way, but for fire and forget calls that's good enough.

Client b106, CitizenFX.FiveM.Client 0.0.3-alpha.

[Gogsi]

Hello, I just updated your post to remove references to mono_rt2. Mono RT2 refers to the Mono v2 runtime in FiveM Legacy - it's not supported and was removed June 30th. Let's call the new runtime just .NET 10 to avoid confusion.

[wolfram-cfx]

Hi, thanks this will be fixed in the next patch.

[Gogsi]

Hello,
A fix for this issue has been implemented in November 11 patch for FiveM for GTAV Enhanced. Please try again and let us know if the issue persists. Thanks for your help!