Skip to content

[BUG] Web PubSub client encodes JSON payloads as strings #50963

Closed

Description

@frankqianms

Describe the bug

WebPubSubClient.sendToGroup and sendEvent encode WebPubSubDataFormat.JSON payloads as escaped JSON strings instead of native JSON values in the reliable JSON protocol frame.

For example, sending {"key":"value"} with WebPubSubDataFormat.JSON produces:

{
  "dataType": "json",
  "data": "{\"key\":\"value\"}"
}

The dataType declares JSON, but the data field is a string. A receiver expecting a typed JSON value cannot process the payload as a JSON object.

No exception is necessarily raised by the client because the Web PubSub service can acknowledge the frame before the receiver attempts to process its contents.

To Reproduce

  1. Create and start a WebPubSubClient using the reliable JSON protocol.
  2. Send a JSON payload using either sendToGroup or sendEvent.
  3. Inspect the outgoing reliable JSON frame or the value delivered to the receiver.

Code Snippet

BinaryData payload = BinaryData.fromString("{\"key\":\"value\"}");

client.sendToGroup("group", payload, WebPubSubDataFormat.JSON);
client.sendEvent("event", payload, WebPubSubDataFormat.JSON);

Both outgoing message serializers currently call writeStringField("data", ...), which escapes the serialized JSON:

  • SendToGroupMessage.toJson
  • SendEventMessage.toJson

Expected behavior

JSON payloads should be written as native JSON values:

{
  "dataType": "json",
  "data": {
    "key": "value"
  }
}

TEXT, BINARY, and PROTOBUF payload encoding should remain unchanged.

Setup (please complete the following information):

  • OS: Any
  • IDE: N/A
  • Library/Libraries: com.azure:azure-messaging-webpubsub-client:1.1.11; also reproducible on the current main branch for 1.2.0-beta.1
  • Java version: Java 8 or later
  • App Server/Environment: Standalone Java application
  • Frameworks: None

Additional context

The incoming GroupDataMessage and ServerDataMessage serializers already preserve JSON values with writeRawField, so outgoing messages should use the same JSON encoding semantics.

Information Checklist

  • Bug Description Added
  • Repro Steps Added
  • Setup information Added

Activity

  1. github-actions commented on Oct 23, 2026

    @github-actions
    Contributor

    Thank you for your feedback. Tagging and routing to the team member(s) best able to assist.

    //cc: Ken Chen (@chenkennt) Liangying.Wei (@vicancy)

  2. github-actions commented on Oct 23, 2026

    @github-actions
    Contributor

    🎯 Agentic Issue Triage

    Summary: WebPubSubClient.sendToGroup/sendEvent write JSON-format payloads as escaped strings (writeStringField) rather than native JSON values in the reliable JSON protocol frame.

    📋 Issue Details

    Package: com.azure:azure-messaging-webpubsub-client (1.1.11; also on main 1.2.0-beta.1)
    Affected API: SendToGroupMessage.toJson, SendEventMessage.toJson
    Scenarios:

    • Send JSON via sendToGroup with WebPubSubDataFormat.JSON
    • Send JSON via sendEvent with WebPubSubDataFormat.JSON

    Root ask: Write JSON payloads as native JSON (e.g. writeRawField), as incoming GroupDataMessage/ServerDataMessage already do; leave TEXT/BINARY/PROTOBUF unchanged.

    🔎 Debugging / Reproduction Notes

    Reporter has already identified the likely cause.

    Suggested investigation steps:

    1. Change writeStringField("data", ...) to writeRawField for the JSON data type in both classes.
    2. Add serialization unit tests asserting data is a JSON object for JSON format and unchanged for other formats.
    3. Update CHANGELOG.
    🏷️ Label Confidence
    • Category: Client — SDK code behavior.
    • Service: WebPubSub — package azure-messaging-webpubsub-client.
    • Confidence: High — single package, unambiguous. Author is an Azure org member (team), so no customer labels. The deprecated-package CSV lookup could not be fetched; the package is actively developed on main, so it is assumed active.
    👥 Owner Routing
    • Matched CODEOWNERS entry: # ServiceLabel: %WebPubSub (line 491)
    • AzureSdkOwners: none listed
    • ServiceOwners: @chenkennt @vicancy
    • Routing action: Service Attention requested; left unassigned.
    • Scan notes: %Mgmt (line 945) did not match since the category is Client.

    Generated by Agentic Triage for #50963 · auto · 21.6 AIC · ⊞ 16.3K · ◷

  3. added
    Service AttentionWorkflow: This issue is responsible by Azure service team.
    ClientThis issue points to a problem in the data-plane of the library.
    on Oct 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    ClientThis issue points to a problem in the data-plane of the library.Service AttentionWorkflow: This issue is responsible by Azure service team.WebPubSub

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions