fix(http-client-csharp): clear diagnostic when client namespace cannot be resolved#10915
Open
JoshLove-msft wants to merge 2 commits into
Conversation
…mespace deserialization failures The playground server intermittently returns 500s when the generator fails to deserialize the root InputNamespace with the opaque message "The JSON value could not be converted to InputNamespace" (name was null). Because parsing a fixed document is deterministic, non-deterministic failures for a spec that always declares a namespace indicate the code model is being mangled/truncated before it reaches the generator. This adds the diagnostics needed to localize the corruption and makes the failure self-explanatory: - Generator: replace the bare `throw new JsonException()` in InputNamespaceConverter with a descriptive message that names the missing 'name' property, while preserving the System.Text.Json Path/line/byte info. - Playground server: log a SHA-256 of the received code model so identical specs that yield different hashes (transport mangling) become visible, and add a write-integrity check that flags when the code model written to disk differs from the received payload (server-side mangling). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
JoshLove-msft
requested review from
ShivangiReja,
jorgerangel-msft,
joseharriaga,
jsquire and
m-nash
as code owners
microsoft-github-policy-service
Bot
added
the
emitter:client:csharp
commit: |
Contributor
|
No changes needing a change description found. |
…ce cannot be resolved When the emitter could not resolve a namespace, it produced a code model with no `name` and still sent it to the generator, which failed with an opaque root-level deserialization error (a 500 on the playground server). Report an actionable `unresolved-client-namespace` diagnostic and skip generation instead. Also remove the pointless server-side write-integrity check. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
JoshLove-msft
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The C# playground server intermittently returned 500 from
POST /generatewith an opaque generator error:The root code model had a
nullname.createModelsetname: getClientNamespaceString(sdkContext)!— the non-null assertion letundefinedthrough,JSON.stringifydropped the property, and the nameless code model failed to deserialize in the generator with a message that gave no clue what was wrong.Why it was intermittent
The playground recompiles on every debounced keystroke and POSTs the code model to the server. The emitter only guards on
!program.hasError()— but a spec with a plainnamespaceand no@servicecompiles with zero errors (verified locally):program.hasError()@servicenamespace (versioned or not)"Foo"namespace Foo;(no@service)undefinedundefinedSo while typing — before
@serviceis added or mid-edit — the buffer is momentarily valid but service-less, and that error-free tick POSTs a nameless model → 500. A moment later the spec has@serviceand it works. It was never the same final spec failing, and never the server corrupting anything.Fix
unresolved-client-namespacediagnostic and skip generation instead of sending a nameless code model. (client-model-builder.ts,emitter.ts,lib.ts)throw new JsonException()inInputNamespaceConverterwith a descriptive message naming the missingnameproperty (defense in depth).GET /route returning 200 to silence Azure App Service availability-probe 404s.Tests
unresolved-client-namespacediagnostic is reported and the code model name is empty.Fixes #10914