BeamGenerateSchema analyzer rejects Dictionary subclasses, Promise<Unit>, and JToken in callable methods

[allister-beamable]

Summary

The Beamable.Microservice.SourceGen Roslyn analyzer rejects three type patterns that are common in production C# microservice code. Chris Hanna noted in a support thread that the analyzer may have become "too overzealous with validations."

Affected patterns

All three were confirmed with a bats integration test suite (dotnet build on a real microservice project, CLI 7.0.1).

1. Dictionary subclass as callable return type

public class MyMap : Dictionary<string, string> { }

[ClientCallable]
public async Task<MyMap> GetMap() { ... }

Error: BEAM_SRV_0021 — the analyzer flags the Object base type of Dictionary<> as non-serializable.

2. Promise<Unit> callable return type

[ClientCallable]
public Promise<Unit> DoWork() { ... }

Error: BEAM_SRV_0012 — Unit is not decorated with [Serializable], so the analyzer rejects it.

3. JToken field in a callable return type

[Serializable]
public class Response { public JToken Payload; }

[ClientCallable]
public async Task<Response> GetData() { ... }

Error: BEAM_SRV_0012 — JToken (Newtonsoft.Json) is not [Serializable], so the analyzer rejects the containing class.

Workaround

Comment out or remove the Beamable.Microservice.SourceGen <PackageReference> in the affected service's .csproj. The build succeeds and the service functions normally without the analyzer present.

Additional note

IsCallableAttribute() in ServicesAnalyzer.cs (around line 1047) walks only one level of inheritance when checking whether an attribute is callable. This means [AdminOnlyCallable] (AdminOnlyCallable : ClientCallable : CallableAttribute — two levels deep) is silently skipped by the analyzer. Methods decorated with [AdminOnlyCallable] do not trigger any BEAM_SRV validation, even for types that would fail under [ClientCallable]. This may be intentional (admin-only callables have fewer serialization requirements at runtime) but it is worth confirming. (See #4591)

Expected behavior

• Dictionary subclasses, Promise<Unit>, and JToken fields should either be explicitly allowed or produce a clear error message that explains why they are rejected and what the recommended replacement pattern is.
• The inheritance-walk depth of IsCallableAttribute() should be documented or deepened to match actual callable attribute hierarchy.

Related

• CLI_CURRENT_DOCS_VERSION hardcoded to "6.1" in Constants.cs — not bumped for 7.x releases #4586 — stale CLI_CURRENT_DOCS_VERSION constant causes all BEAM_SRV error help links to point to CLI-6.1 docs instead of CLI-7.0

[cdhanna]

There are several things going on here,

1. Unit should just be serializable, all done.
2. JToken is kind of confusing
3. Dictionary support should move to become an Unreal specific thing
4. AdminOnlyCallable vs ServerCallable vs ClientCallable's client generation flag causes different levels of compiler errors because different protections are in place for "is client code going to generate"; but that decision should be more explicit, and we need to understand how it will work in a world where we expect folks to generate multiple client languages (web + C#/C++)

[allister-beamable]

Created #4591 to address the client generation aspect of point 4 in Chris's recent comment.

[cdhanna]

For the [serializable] attribute, we should add a csproj config level setting allowing the user to opt OUT of enforcing the attribute. The error message BEAM_SRV_0012 should include a hint for how to opt out.