Validation and diagnostics for connector configurations

[daviburg]

Summary

Implement LSP diagnostics (error/warning squiggles) for SDK connector configurations in C# projects. The LSP currently provides rich IntelliSense (completions, hover, CodeLens, code actions) but does not surface validation errors to the editor.

Related: azure-functions-bucees-planning#912 — [Connectors] LSP release - C#

Background

The LSP already builds a Roslyn CSharpCompilation per request and indexes the SDK via reflection (SdkIndex). It resolves connector names, operations, trigger payloads, dynamic values, and connections — but validation failures are only logged to stderr, never published as textDocument/publishDiagnostics.

Scope

Add a diagnostics pipeline that publishes warnings and errors to the editor when SDK usage is incorrect. The diagnostics are grouped into sub-issues below, each sized for a single session/PR.

Sub-Issues

#	Title	Diagnostics	Effort
#39	Diagnostics infrastructure — DiagnosticPublisher and validator pipeline	Foundation	Medium
#40	Attribute validation (ConnectorName, OperationName, ConnectorTriggerMetadata)	CSDK001–CSDK009	Small–Medium
#41	Connection configuration validation	CSDK100–CSDK105	Small–Medium
#42	Trigger payload type validation	CSDK200–CSDK204	Medium
#43	DynamicValues and DynamicSchema validation	CSDK300–CSDK307	Small–Medium
#44	SDK usage patterns and anti-pattern detection	CSDK400–CSDK407	Small–Medium

Total: 36 diagnostics across 5 validator categories plus the infrastructure.

Architecture

TextDocumentSyncHandler (on open/save/change)
    -> DiagnosticPublisher
        -> IDiagnosticValidator[] (one per category)
            -> AttributeValidator (SdkIndex + Roslyn)          #40
            -> ConnectionValidator (ConnectionsService)         #41
            -> TriggerPayloadValidator (SdkIndex + Roslyn)      #42
            -> DynamicValuesValidator (DynamicOperationsRegistry) #43
            -> UsagePatternValidator (Roslyn semantic model)    #44
        -> server.SendNotification(""textDocument/publishDiagnostics"", ...)

Each validator receives the document URI, document text, SdkIndex, and services, and returns a list of Diagnostic objects with severity, range, code, and message.

Diagnostic Code Ranges

Range	Category	Sub-Issue
CSDK001–CSDK099	Attribute validation	#40
CSDK100–CSDK199	Connection configuration	#41
CSDK200–CSDK299	Trigger payload types	#42
CSDK300–CSDK399	DynamicValues / DynamicSchema	#43
CSDK400–CSDK499	SDK usage patterns	#44

Implementation Order

1. Diagnostics infrastructure — DiagnosticPublisher and validator pipeline #39 — Infrastructure first (all others depend on it)
2. Diagnostics: attribute validation (ConnectorName, OperationName, ConnectorTriggerMetadata) #40 — Attribute validation (highest impact, most data already in SdkIndex)
3. Diagnostics: connection configuration validation #41 — Connection validation (second most common pain point)
4. Diagnostics: trigger payload type validation #42–Diagnostics: SDK usage patterns and anti-pattern detection #44 — Can be done in parallel after infrastructure is in place

Out of Scope (Large effort — future work)

• Static call graph analysis (operation referenced but never invoked)
• Cross-file test coverage detection
• Dependency loop detection in parameter chains
• Deep data flow analysis for parameter lifecycle
• Schema structural validation (nested untyped objects)