C# playground server: intermittent 500 from non-deterministic root InputNamespace deserialization (name missing / mangled code model)

[JoshLove-msft]

Summary

The C# playground server (csharp-playground-server.azurewebsites.net) intermittently returns 500 from POST /generate. The generator subprocess exits with code 1 and logs:

The JSON value could not be converted to Microsoft.TypeSpec.Generator.Input.InputNamespace. Path: $ | LineNumber: 6 | BytePositionInLine: 1.
   at Microsoft.TypeSpec.Generator.Input.InputNamespaceConverter.ReadInputNamespace(...)
   at Microsoft.TypeSpec.Generator.Input.TypeSpecSerialization.Deserialize(...)
   at Microsoft.TypeSpec.Generator.Input.InputLibrary.Load(...)

The stack trace points at InputNamespaceConverter.ReadInputNamespace, where the only JsonException for the root is name ?? throw — i.e. the root code model object has no name property (the root object ends by line 6, so the document the generator parsed is tiny/truncated).

Why this is suspicious

• The failure is non-deterministic for specs that always declare a namespace.
• Deserializing a fixed JSON document is deterministic and single-threaded, and the playground server writes each request to a unique temp dir, so the same bytes can't parse differently across runs.
• Therefore the bytes reaching the generator must differ between runs — the code model appears to be mangled/truncated somewhere between the browser emitter producing it and the generator parsing it (transport, the server's write path, or the emitter's serialization).

Current gap

The bare throw new JsonException() produces an opaque could not be converted to InputNamespace with no indication of which field is missing, and the server keeps no fingerprint of the payload, so the corruption can't be localized from telemetry.

Proposed work (diagnostics first)

1. Generator: make the exception name the missing name field (keep STJ Path/line/byte).
2. Playground server: log a SHA-256 of the received code model (identical specs must hash identically), and add a write/read integrity check to flag server-side mangling.

Once telemetry confirms where the bytes diverge (transport vs. server write vs. emitter output) we can fix the root cause.

A first PR adding the diagnostics + a descriptive error is linked below.

[github-actions]

🎯 Issue Triage

The C# playground server (csharp-playground-server.azurewebsites.net) intermittently returns HTTP 500 on POST /generate because the generator receives a mangled/truncated code model JSON, causing InputNamespaceConverter to fail deserializing the root InputNamespace (missing name field). The failure is non-deterministic, pointing to corruption somewhere in the transport or server write path rather than in the TypeSpec spec itself.

Category: Bug
Area: emitter:client:csharp

⚠️ No reproduction provided. The intermittent nature makes a standalone repro difficult; the proposed diagnostics (SHA-256 payload fingerprinting + better exception messages) are the right first step to localize the corruption.

🔍 Analysis

• Root issue: InputNamespaceConverter.ReadInputNamespace throws an opaque JsonException when the name field is absent at the root. The only codepath that throws for the root object is name ?? throw new JsonException(), confirming the payload is truncated before name is written (root ends at line 6).
• Non-determinism: The same TypeSpec spec parses to a fixed JSON blob. Deserialization is deterministic, so the corruption happens before the generator reads it — likely in the playground server's write path or in transport between browser and server.
• Affected components:
  • Microsoft.TypeSpec.Generator.Input.InputNamespaceConverter (opaque error message)
  • Microsoft.TypeSpec.Generator.Input.TypeSpecSerialization.Deserialize
  • C# playground server (csharp-playground-server.azurewebsites.net) write/log path
• Proposed fix direction (from issue author):
  1. Improve the JsonException message to name the missing field.
  2. Add SHA-256 payload fingerprinting and write/read integrity check on the playground server side.
• No existing duplicate issues found.

📝 Suggested next steps

• In InputNamespaceConverter.ReadInputNamespace, replace the bare throw new JsonException() with a message that identifies the missing name field.
• In the playground server, log a SHA-256 of the received code model payload per request to detect corruption across runs.
• Add a write/read integrity check (write → read back → compare hash) to isolate server-side mangling.
• After diagnostics are in place, correlate logs to determine whether corruption is in transport, the server write path, or the browser emitter serialization.

Generated by Agentic Triage

[JoshLove-msft]

Root cause confirmed

The intermittent 500 is not transport/server corruption. When the emitter cannot resolve a service namespace, createModel built the root code model with name: getClientNamespaceString(sdkContext)! — the non-null assertion let undefined through, JSON.stringify dropped the name property, and the resulting nameless code model failed InputNamespace deserialization in the generator with the opaque message in this issue.

The playground compile path was ruled out as the source of mangling: useCompilation serializes compiles via isCompilingRef (the full compile(), including the emitter's awaited POST, runs inside the guard), so the emitter always receives the complete source snapshot.

Fix (#10915)

• Emitter reports a clear unresolved-client-namespace diagnostic and skips generation instead of sending a nameless code model.
• Generator throws a descriptive deserialization error naming the missing name property.
• Playground server adds a root GET / route (silences App Service probe 404s).

--generated by Copilot

[JoshLove-msft]

Why it was intermittent (confirmed with a local repro)

The failure isn't a corrupted payload or a race — it's transient intermediate edit states.

The playground recompiles on every debounced keystroke (500 ms for C#) and POSTs the resulting code model to the server. The emitter only guards on !program.hasError() — but a spec with a plain namespace and no @service decorator compiles with zero errors:

spec	resolved namespace	program.hasError()
@service namespace (versioned or not)	"Foo"	false
plain namespace Foo; (no @service)	undefined	false
no namespace at all	undefined	false

So while the user is typing — before @service is added, or mid-edit on the service/namespace line — the buffer is momentarily valid but service-less. That error-free tick fires the emitter, which builds a code model with name: getClientNamespaceString(sdkContext)! (undefined), JSON.stringify drops name, and the server relays a nameless model that the generator rejects → 500. A moment later the spec has @service again and it works.

This matches every observation:

• non-deterministic → depends on editing/debounce timing, not the final spec
• "the namespace is always in the tsp" → the namespace keyword is there; the @service that TCGC actually requires is intermittently absent
• not the server → the server faithfully relays an already-nameless model
• "how the tsp is sent to the emitter" → the playground sends every error-free intermediate compile to the emitter/server, including service-less ones, because missing @service is not a compile error

Fix (#10915)

Report a clear unresolved-client-namespace diagnostic and skip generation when no namespace resolves, so these transient states no longer POST a nameless model (no 500) and the final spec gets an actionable message instead of an opaque generator error.

--generated by Copilot