Add api version 2024-10-01-preview for Azure SignalR and Azure Web PubSub

[bjqian]

ARM (Control Plane) API Specification Update Pull Request

[!TIP] Overwhelmed by all this guidance? See the Getting help section at the bottom of this PR description.

PR review workflow diagram

Please understand this diagram before proceeding. It explains how to get your PR approved & merged.

Purpose of this PR

What's the purpose of this PR? Check the specific option that applies. This is mandatory!

• [ ] New resource provider.
• [x] New API version for an existing resource provider. (If API spec is not defined in TypeSpec, the PR should have been created in adherence to OpenAPI specs PR creation guidance).
• [ ] Update existing version for a new feature. (This is applicable only when you are revising a private preview API version.)
• [ ] Update existing version to fix OpenAPI spec quality issues in S360.
• [ ] Convert existing OpenAPI spec to TypeSpec spec (do not combine this with implementing changes for a new API version).
• [ ] Other, please clarify:
  • edit this with your clarification

Due diligence checklist

To merge this PR, you must go through the following checklist and confirm you understood and followed the instructions by checking all the boxes:

• [x] I confirm this PR is modifying Azure Resource Manager (ARM) related specifications, and not data plane related specifications.
• [x] I have reviewed following Resource Provider guidelines, including ARM resource provider contract and REST guidelines (estimated time: 4 hours).
  I understand this is required before I can proceed to the diagram Step 2, "ARM API changes review", for this PR.

Additional information

Viewing API changes

For convenient view of the API changes made by this PR, refer to the URLs provided in the table in the `Generated ApiView` comment added to this PR. You can use ApiView to show API versions diff.

Suppressing failures

If one or multiple validation error/warning suppression(s) is detected in your PR, please follow the [suppressions guide](https://aka.ms/azsdk/pr-suppressions) to get approval.

Getting help

• First, please carefully read through this PR description, from top to bottom. Please fill out the Purpose of this PR and Due diligence checklist.
• If you don't have permissions to remove or add labels to the PR, request write access per aka.ms/azsdk/access#request-access-to-rest-api-or-sdk-repositories
• To understand what you must do next to merge this PR, see the Next Steps to Merge comment. It will appear within few minutes of submitting this PR and will continue to be up-to-date with current PR state.
• For guidance on fixing this PR CI check failures, see the hyperlinks provided in given failure and https://aka.ms/ci-fix.
• For help with ARM review (PR workflow diagram Step 2), see https://aka.ms/azsdk/pr-arm-review.
• If the PR CI checks appear to be stuck in queued state, please add a comment with contents /azp run. This should result in a new comment denoting a PR validation pipeline has started and the checks should be updated after few minutes.
• If the help provided by the previous points is not enough, post to https://aka.ms/azsdk/support/specreview-channel and link to this PR.

[openapi-pipeline-app[bot]]

Next Steps to Merge

✅ All automated merging requirements have been met! To get your PR merged, see aka.ms/azsdk/specreview/merge.

[openapi-pipeline-app[bot]]

Generated ApiView

Language	Package Name	ApiView Link
Go	sdk/resourcemanager/signalr/armsignalr	https://apiview.dev/Assemblies/Review/454fa36be1744f6282a36247b001738e?revisionId=e29b3ea92c0a4b1eb09c9c35c656866b
Go	sdk/resourcemanager/webpubsub/armwebpubsub	https://apiview.dev/Assemblies/Review/063845482f6d4a84b8cd66b982770577?revisionId=9186879460d4412fb1da9441fce3c0a1
.Net	Azure.ResourceManager.WebPubSub	There is no API change compared with the previous version
JavaScript	@azure/arm-signalr	https://apiview.dev/Assemblies/Review/19dcf3a0cb214c9eb26656d78f00c556?revisionId=30dfc09302ef4d5491adc36dff996910
JavaScript	@azure/arm-webpubsub	https://apiview.dev/Assemblies/Review/a8172261dd334c3c939f4c623fd83907?revisionId=ceec4f73791643019042f61df4a3eb0a
Python	azure-mgmt-signalr	https://apiview.dev/Assemblies/Review/b760607d857b4332aa3d2893df068ed5?revisionId=ab5074bac23c49edafc5ee14dfc61f62
Python	azure-mgmt-webpubsub	https://apiview.dev/Assemblies/Review/f8c77e10962543998f8e9d2357fd7a1e?revisionId=00a9af9da9f44de484550697fea31d0e
Java	azure-resourcemanager-signalr	https://apiview.dev/Assemblies/Review/aa1e87da06d14e96ade025aacaab4de3?revisionId=94c7924aa34a4d44bce03a21803c72e6
Java	azure-resourcemanager-webpubsub	There is no API change compared with the previous version
Swagger	Microsoft.SignalRService	https://apiview.dev/Assemblies/Review/c19018e1a4434887ae6482edbd28f151?revisionId=9905a15f99e54594bd5a864984d1f0c0

[razvanbadea-msft]

    "maxInboundMessageBytes": {

if there is a 1GB as default why did you not set it? like you added for aggregationWindowInSeconds

---

Refers to: specification/signalr/resource-manager/Microsoft.SignalRService/preview/2024-10-01-preview/signalr.json:3743 in beb58ba. [](commit_id = beb58bae6ea20745963ae7853c3f034e46469f15, deletion_comment = False)

[razvanbadea-msft]

      "description": "Gets or sets the Keep-Alive Interval. Optional to set.\r\nValue is in seconds.\r\nThe default value is 15 seconds.\r\nCustomers should set this value to a shorter period if they want the service to send keep-alive messages more frequently, \r\nensuring timely checks of the connection status.\r\nConversely, customers can set this value to a longer period if they want the service to send keep-alive messages less frequently, \r\nreducing network traffic, but note that it may take longer to detect a disconnection.\r\nThis interval ensures that the connection is maintained by sending periodic keep-alive messages to the client.",

same thing about adding also a default

---

Refers to: specification/signalr/resource-manager/Microsoft.SignalRService/preview/2024-10-01-preview/signalr.json:3044 in beb58ba. [](commit_id = beb58bae6ea20745963ae7853c3f034e46469f15, deletion_comment = False)

[razvanbadea-msft]

      "description": "Rules to control the client traffic",

you can specify in the description that you cant add more than 10

---

Refers to: specification/signalr/resource-manager/Microsoft.SignalRService/preview/2024-10-01-preview/signalr.json:2157 in beb58ba. [](commit_id = beb58bae6ea20745963ae7853c3f034e46469f15, deletion_comment = False)

[razvanbadea-msft]

    "maxInboundMessageBytes": {

same comment in this file about default attribute

---

Refers to: specification/webpubsub/resource-manager/Microsoft.SignalRService/preview/2024-10-01-preview/webpubsub.json:3776 in beb58ba. [](commit_id = beb58bae6ea20745963ae7853c3f034e46469f15, deletion_comment = False)

[bjqian]

      "description": "Gets or sets the Keep-Alive Interval. Optional to set.\r\nValue is in seconds.\r\nThe default value is 15 seconds.\r\nCustomers should set this value to a shorter period if they want the service to send keep-alive messages more frequently, \r\nensuring timely checks of the connection status.\r\nConversely, customers can set this value to a longer period if they want the service to send keep-alive messages less frequently, \r\nreducing network traffic, but note that it may take longer to detect a disconnection.\r\nThis interval ensures that the connection is maintained by sending periodic keep-alive messages to the client.",

same thing about adding also a default

Refers to: specification/signalr/resource-manager/Microsoft.SignalRService/preview/2024-10-01-preview/signalr.json:3044 in beb58ba. [](commit_id = beb58ba, deletion_comment = False)

Hi @razvanbadea-msft . In this PR review , I found a new rule: It's telling us to remove the swagger default value in the patch body. I'm confused whether or not we should mark the default value in the swagger. 😂

[razvanbadea-msft]

      "description": "Gets or sets the Keep-Alive Interval. Optional to set.\r\nValue is in seconds.\r\nThe default value is 15 seconds.\r\nCustomers should set this value to a shorter period if they want the service to send keep-alive messages more frequently, \r\nensuring timely checks of the connection status.\r\nConversely, customers can set this value to a longer period if they want the service to send keep-alive messages less frequently, \r\nreducing network traffic, but note that it may take longer to detect a disconnection.\r\nThis interval ensures that the connection is maintained by sending periodic keep-alive messages to the client.",

same thing about adding also a default Refers to: specification/signalr/resource-manager/Microsoft.SignalRService/preview/2024-10-01-preview/signalr.json:3044 in beb58ba. [](commit_id = beb58ba, deletion_comment = False)

Hi @razvanbadea-msft . In this PR review , I found a new rule: It's telling us to remove the swagger default value in the patch body. I'm confused whether or not we should mark the default value in the swagger. 😂

for patch operations: A recommended way is to define a new model that only contains the patchable properties to replace the original parameter in request body. - https://github.com/Azure/azure-openapi-validator/blob/main/docs/patch-body-parameters-schema.md#how-to-fix

are those properties patchable or can be excluded from it?

[bjqian]

Hi @razvanbadea-msft .

Thanks for the clarification! I understand the recommended approach is to use a separate model for patch if a model contains "default/required" properties.

Let me elaborate a bit on the issue:

Yes, those properties are pachable. However, the two properties in question were introduced in a model from a previous API version. Switching to a new model could potentially break existing client code.

In our Resource Provider, the actual behavior for default value in the comment is as follows:

• For Create operations, our RP fills in the default value if these properties are omitted.
• For Patch operations, the fields are left untouched if they are not provided.

In this way, we could avoid introducing "swagger default" in the client side.

Thank you again for highlighting this issue! Please let us know if you'd like more details or further clarification.