DentSignal engineering case study · Cloud integration

The connection opened. The session still failed.

Azure-hosted telemetry showed a successful WebSocket connection followed by a rejected settings message. That moved the investigation away from infrastructure and toward one payload shape.

Area: Azure telemetry, Python, WebSockets
Evidence: Historical PR-reported validation
Boundary: Application config, not Azure migration

Plain English

Connected is not the same as accepted.

What broke
The network connection succeeded, but the provider rejected an unsupported nested setting before useful output began.
What changed
The rejected object was removed, supported values were constrained, and the exact payload shape received regression coverage.
Why it matters
Telemetry kept the repair narrow. There was no reason to rebuild cloud infrastructure when the failure occurred after connection.

Simplified repair

Send only what the provider accepts.

Broken · simplified example

settings = {
    "threshold": 0.8,
    "nested": unsupported_options,
}
socket.send(settings)

The socket is healthy, but the first meaningful message is rejected.

Fixed · simplified example

settings = {
    "threshold": valid_threshold,
}
socket.send(settings)
assert event == "SettingsApplied"

The correction removes the unsupported shape and verifies provider acceptance.

Illustration only — not copied from private source.

How it was checked

Historical PR-reported validation

The cited history reports 182 focused tests, 306 broader tests, Ruff, secret and external-service guards, and a controlled no-audio handshake that returned SettingsApplied.