Add workflow issue triage 6787 (#11) * Add backward compatibility support for constructor accessibility on abstract base types (#9484) ## Problem Regenerating SDKs from TypeSpec (previously from autorest) changes constructor accessibility on abstract base types, breaking existing code. Example from Azure.Search.Documents: **Previous (autorest):** ```csharp public abstract partial class SearchIndexerDataIdentity { public SearchIndexerDataIdentity() { } } ``` **Current (TypeSpec without fix):** ```csharp public abstract partial class SearchIndexerDataIdentity { private protected SearchIndexerDataIdentity(string odataType) { } // Constructor is private protected instead of public } ``` ## Changes ### Core Implementation - **TypeProvider.ProcessTypeForBackCompatibility**: Extended to process constructors in addition to methods - **TypeProvider.BuildConstructorsForBackCompatibility**: New virtual method for constructor backward compatibility logic - **ModelProvider.BuildConstructorsForBackCompatibility**: Changes constructor modifiers from `private protected` to `public` on abstract base types when the last contract had a public constructor with matching parameters ### Approach This implementation changes the accessibility modifier on existing constructors rather than generating new ones. It only applies when: 1. The type is an abstract base type 2. The last contract had a public constructor 3. The current version generates a `private protected` constructor with matching parameters (same count, types, and names) ### Generated Code ```csharp public abstract partial class SearchIndexerDataIdentity { ///

Initializes a new instance of SearchIndexerDataIdentity.

public SearchIndexerDataIdentity(string odataType) { OdataType = odataType; } } ``` ## Testing - Added `BackCompat_AbstractTypeConstructorAccessibility` test that verifies constructor modifiers change from `private protected` to `public` - All 1231 tests pass - Updated documentation with new "Model Constructors" section

Original prompt

---- *This section details on the original issue you should resolve* [Bug]: Backward Compatibility not generating pre-existing public constructors ### Describe the bug Pre-existing public constructors should not be missing from the generated code. This should be another Back Compat scenario. See [Backward Compatibility Support](https://github.com/microsoft/typespec/blob/main/packages/http-client-csharp/generator/docs/backward-compatibility.md) for more details. Generating Azure.Search.Documents have the issue where a public constructor is missing, for instance, this is what the previously generated code from autorest looks like: ```csharp // Copyright (c) Microsoft Corporation. All rights reserved. // Licensed under the MIT License. // #nullable disable using System; using System.Collections.Generic; namespace Azure.Search.Documents.Indexes.Models { ///

/// Abstract base type for data identities. /// Please note is the base class. According to the scenario, a derived class of the base class might need to be assigned here, or this property needs to be casted to one of the possible derived classes. /// The available derived classes include and . ///

public abstract partial class SearchIndexerDataIdentity { ///

/// Keeps track of any properties unknown to the library. /// /// To assign an object to the value of this property use . /// /// /// To assign an already formatted json string to this property use . /// /// /// Examples: /// /// /// BinaryData.FromObjectAsJson("foo") /// Creates a payload of "foo". /// /// /// BinaryData.FromString("\"foo\"") /// Creates a payload of "foo". /// /// /// BinaryData.FromObjectAsJson(new { key = "value" }) /// Creates a payload of { "key": "value" }. /// /// /// BinaryData.FromString("{\"key\": \"value\"}") /// Creates a payload of { "key": "value" }. /// /// /// ///

private protected IDictionary _serializedAdditionalRawData; ///

Initializes a new instance of .

public SearchIndexerDataIdentity() { } ///

Initializes a new instance of .

/// A URI fragment specifying the type of identity. /// Keeps track of any properties unknown to the library. internal SearchIndexerDataIdentity(string oDataType, IDictionary serializedAdditionalRawData) { ODataType = oDataType; _serializedAdditionalRawData = serializedAdditionalRawData; } ///

A URI fragment specifying the type of identity.

internal string ODataType { get; set; } } } ``` and the new generated model looks like: ```csharp // Copyright (c) Microsoft Corporation. All rights reserved. // Licensed under the MIT License. // #nullable disable using System; using System.Collections.Generic; namespace Azure.Search.Documents.Models { ///

/// Abstract base type for data identities. /// Please note this is the abstract base class. The derived classes available for instantiation are: and . ///

public abstract partial class SearchIndexerDataIdentity { ///

Keeps track of any properties unknown to the library.

private protected readonly IDictionary _additionalBinaryDataProperties; ///

Initializes a new instance of .

/// A URI fragment specifying the type of identity. private protected SearchIndexerDataIdentity(string odataType) { OdataType = odataType; } ///

Initializes a new instance of .

...

- Fixes microsoft/typespec#9483 --- 💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more [Copilot coding agent tips](https://gh.io/copilot-coding-agent-tips) in the docs. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: JonathanCrd <17486462+JonathanCrd@users.noreply.github.com> Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com> Co-authored-by: jolov * Remove unused `program` param from `isArrayModelType` and `isRecordModelType` (#9336) ## Summary Added overloads to `isArrayModelType` and `isRecordModelType` that don't require the unused program parameter. The old signature is deprecated but still works for backward compatibility. ## Usage ```javascript // New (preferred) isArrayModelType(type) isRecordModelType(type) // Old (deprecated, still works) isArrayModelType(program, type) isRecordModelType(program, type) ``` * Input Type Updates for Xml Serialization Support (#9489) Adds updates to the input types in preparation for adding xml serialization support. contributes to : https://github.com/microsoft/typespec/issues/5645 * [python] correctly deserialize xml errors (#9488) Co-authored-by: iscai-msft * [specs] add xml error response test (#9499) Co-authored-by: iscai-msft * Api Version Parameter Reinjection (#9493) This pull request improves how API version parameters are handled, specifically ensuring that API version query parameters are correctly reinjected during pagination scenarios. It also adds a test to validate this behavior. **Pagination and Parameter Reinjection Improvements:** * Added logic to ensure API version parameters (those marked as `IsApiVersion`) are preserved and reinjected across pagination requests in the `GetReinjectedParametersMap` method of `RestClientProvider`. * Updated the `ShouldSkipReinjectedParameter` method to skip both `maxpagesize` and `api-version` parameters when determining which parameters to reinject, preventing unnecessary reinjection of these special parameters. * Defined a constant for the API version parameter name (`ApiVersionParameterName`) to improve maintainability and clarity. **Testing Enhancements:** * Added a new unit test, `TestApiVersionParameterReinjectedInCreateNextRequestMethod`, to verify that the generated client code correctly reinjects the `api-version` parameter during pagination. Solves: https://github.com/microsoft/typespec/issues/9492 * Support 3xx redirect status codes in http-client-csharp generator (#9498) ## Plan: Add support for 302 redirect in http-client-csharp - [x] Understand the issue from migration blocker document - [x] Identify root cause in RestClientProvider.GetClassifier - [x] Update GetSuccessStatusCodes to include 3xx status codes - [x] Add test case for 302 redirect in http-client-csharp - [x] Validate test passes with changes - [x] Run broader test suite to ensure no regressions - [x] Code review and address feedback - [x] COMPLETE ### Summary Successfully added support for HTTP 3xx redirect status codes (including 302) to the http-client-csharp emitter. ### Changes Made 1. **RestClientProvider.cs** (1 line changed): - Line 862: Changed from `statusCode < 300` to `statusCode < 400` - Allows 3xx redirect status codes to be treated as success responses 2. **Unit test**: - Added `Validate3xxRedirectStatusCode` test in `RestClientProviderTests.cs` to verify 302 redirect support - Test validates proper pipeline message classifier creation for 3xx status codes - Test validates that the CreateRequest method properly references and uses the classifier property - Test is self-contained and uses InputFactory to create test data ### Test Results ✅ All 1010 unit tests pass (Microsoft.TypeSpec.Generator.ClientModel.Tests) ✅ New test specifically validates 302 redirect functionality including CreateRequest method behavior ✅ No regressions in existing functionality ### Migration Blocker Resolution This resolves the migration blocker for Azure.Communication.ProgrammableConnectivity which uses 302 redirects in its OAuth authorization flow. The service can now migrate from the legacy emitter to http-client-csharp v1.0.0+.

Original prompt

> > ---- > > *This section details on the original issue you should resolve* > > Add support for 302 redirect > See https://github.com/Azure/azure-sdk-for-net/blob/8401911d737002189207067dde4177ea94846126/sdk/communication/Azure.Communication.ProgrammableConnectivity/MIGRATION_BLOCKER.md > > ## Comments on the Issue (you are @copilot in this section) > > > >

- Fixes microsoft/typespec#9497 --- 💬 We'd love your input! Share your thoughts on Copilot coding agent in our [2 minute survey](https://gh.io/copilot-coding-agent-survey). --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com> * Migrate Create-APIReview script from API Key to Azure AD authentication (#9501) - [x] Review Azure SDK PR #13235 pattern for removing API Key authentication - [x] Update Create-APIReview.ps1 to remove API Key parameter and add Bearer token authentication - Removed `$APIKey` parameter from script - Added `Get-ApiViewBearerToken()` function that acquires Azure AD tokens via `az account get-access-token` - Updated `Upload-SourceArtifact` to use Bearer token instead of API Key - Updated `Upload-ReviewTokenFile` to use Bearer token instead of API Key - Changed API endpoints from `UploadAutoReview` to `upload` and `CreateApiReview` to `create` (lowercase) - Changed HTTP method from GET to POST for the create endpoint - Improved error handling with more detailed error messages - [x] Update create-apireview.yml to use AzureCLI@2 task instead of Powershell@2 task - Changed task from `Powershell@2` to `AzureCLI@2` - Added `AzureServiceConnection` parameter with default value "APIView prod deployment" - Removed `-APIKey $(azuresdk-apiview-apikey)` argument - Removed `pwsh: true` (not needed with AzureCLI@2) - Added `azureSubscription`, `scriptType`, and `scriptLocation` inputs - [x] Address security concern: removed potentially sensitive token response from error logging

Original prompt

> > ---- > > *This section details on the original issue you should resolve* > > Stop using Api Key in Create-ApiReview script > We can follow the same pattern as used in https://github.com/Azure/azure-sdk-tools/pull/13235 > > And apply those changes to https://github.com/microsoft/typespec/blob/main/eng/emitters/scripts/Create-APIReview.ps1 > > Also need to update https://github.com/microsoft/typespec/blob/main/eng/emitters/pipelines/templates/steps/create-apireview.yml > > ## Comments on the Issue (you are @copilot in this section) > > > >

- Fixes microsoft/typespec#9500 --- 💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more [Copilot coding agent tips](https://gh.io/copilot-coding-agent-tips) in the docs. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com> * Rename from "top" to "maxCount" in paging operations (#9505) This pull request updates the C# HTTP client generator to improve parameter naming consistency for paging operations. Specifically, it ensures that the "top" query parameter is renamed to "maxCount" in generated REST client methods, and adds a corresponding unit test to verify this behavior. Additionally, the `InputParameter.Update` method is enhanced to allow updating multiple fields at once. Solves: https://github.com/microsoft/typespec/issues/9502 * [python] release new version (#9507) * Fix optional Content-Type headers being transformed to enums (emitter-only) (#9495) Optional Content-Type headers were incorrectly transformed into extensible enums by the type converter. They must remain as constants. ## Changes **Emitter (type-converter.ts)** - Skip enum transformation for Content-Type headers, preserving constant type regardless of optionality **Emitter (operation-converter.ts)** - Pass header parameter to `fromSdkType` to enable Content-Type detection **Emitter Tests (operation-converter.test.ts)** - Added tests to verify Content-Type remains as constant type for both optional and required bodies ## Result Content-Type headers now remain as constants in the type model instead of being transformed to enums when the body parameter is optional. This prevents the enum transformation while preserving the constant type information for downstream processing. ## Note This PR focuses solely on the emitter-side fix to prevent unwanted enum transformation. Generator-side handling of optional Content-Type parameters (if needed for conditional setting) will be addressed separately.

Original prompt

> > ---- > > *This section details on the original issue you should resolve* > > Bump SCM to 1.9.0 > Bump System.ClientModel package to 1.9.0 both in our [generator source](https://github.com/microsoft/typespec/blob/main/packages/http-client-csharp/generator/Packages.Data.props#L17) and in the generated project file. > > ## Comments on the Issue (you are @copilot in this section) > > > >

- Fixes microsoft/typespec#9518 --- 💬 We'd love your input! Share your thoughts on Copilot coding agent in our [2 minute survey](https://gh.io/copilot-coding-agent-survey). --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: jorgerangel-msft <102122018+jorgerangel-msft@users.noreply.github.com> * [python] release new version (#9525) * Bump tar from 7.5.3 to 7.5.7 in /packages/http-client-java (#9524) Bumps [tar](https://github.com/isaacs/node-tar) from 7.5.3 to 7.5.7.

Commits

4a37eb9 7.5.7
f4a7aa9 fix: properly sanitize hard links containing ..
394ece6 7.5.6
7d4cc17 fix race puting a Link ahead of its target File
26ab904 7.5.5
e9a1ddb fix: do not prevent valid linkpaths within archive
911c886 7.5.4
3b1abfa normalize out unicode ligatures
a43478c remove some unused files
970c58f update deps
Additional commits viewable in compare view

Maintainer changes

This version was pushed to npm by isaacs, a new releaser for tar since your current version.

[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=tar&package-manager=npm_and_yarn&previous-version=7.5.3&new-version=7.5.7)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) ---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/microsoft/typespec/network/alerts).

Signed-off-by: dependabot[bot] Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Fix optional Content-Type header detection by unifying parameter processing (#9528) - [x] Understand the issue: The previous fix in PR #9495 added Content-Type header detection in `type-converter.ts`, but it relies on `sdkProperty` being passed to `fromSdkType`. The `fromHeaderParameter` function in `operation-converter.ts` doesn't pass the header parameter to `fromSdkType`, so the fix doesn't work. - [x] Fix `fromHeaderParameter` to pass the header parameter `p` to `fromSdkType` so the Content-Type detection can work - [x] Unify all parameter-processing functions to pass property instance to `fromSdkType`: - `fromQueryParameter` - `fromPathParameter` - `fromHeaderParameter` - `fromBodyParameter` - `updateMethodParameter` - [x] Investigated making `sdkProperty` required - not feasible as many callers have no property context (model base types, array/dict value types, etc.) - [x] Run existing tests to verify the fix works (all 177 tests pass) - [x] Fix CI formatting issues - [x] Run code review and security checks

Original prompt

> > ---- > > *This section details on the original issue you should resolve* > > Fix optional contentType issue > As described in https://github.com/Azure/azure-sdk-for-net/issues/55300, but the issue belongs in this repo. > > The previous [fix ](https://github.com/microsoft/typespec/pull/9495) does not really fix the issue entirely. > Please fix this again following the root cause in this comment: https://github.com/microsoft/typespec/issues/9494#issuecomment-3822513806 > > ## Comments on the Issue (you are @copilot in this section) > > > @ArcturusZhang > I think this is not fixed. > The fix introduced an extra check to see if it is a content type header, by checking if the `sdkProperty` is not undefined, but in our code, when the `fromSdkType` is called converting the method parameters (for instance [here](https://github.com/microsoft/typespec/blob/f1a7649b3b53ab7d30488cf7274f813696cdf2d0/packages/http-client-csharp/emitter/src/lib/operation-converter.ts#L482)), the `sdkProperty` argument is never passed in. Therefore the fix is not actually running. > >

- Fixes microsoft/typespec#9494 --- 💬 We'd love your input! Share your thoughts on Copilot coding agent in our [2 minute survey](https://gh.io/copilot-coding-agent-survey). --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: ArcturusZhang <10554446+ArcturusZhang@users.noreply.github.com> * Add backward compatibility for object-typed AdditionalProperties (#9516) ## ✅ Implementation Complete: Add backward compatibility support for object-typed AdditionalProperties ### Issue Resolved Successfully implemented backward compatibility for models with `IDictionary` AdditionalProperties (from old generator) that are now generated as `IDictionary` (in new generator). ### Final Solution **Core Approach: Matching Backing Field Types** The solution detects when a model previously had object-typed AdditionalProperties and creates the backing field with the appropriate type, ensuring perfect type alignment between field and property. ### Files Changed **packages/http-client-csharp/generator/Microsoft.TypeSpec.Generator/src/Providers/ModelProvider.cs** - Added object dictionary type support alongside BinaryData - Added early backward compatibility detection via `ShouldUseObjectAdditionalProperties()` - Updated `BuildRawDataField()` to create field with object or BinaryData type based on backward compat needs - Updated property generation logic to use matching backing field type - Added comprehensive XML documentation - Fixed null-safety issues with IsFrameworkType checks **packages/http-client-csharp/generator/Microsoft.TypeSpec.Generator/test/Providers/ModelProviders/ModelProviderTests.cs** - Added `TestBuildProperties_WithObjectAdditionalPropertiesBackwardCompatibility` test **packages/http-client-csharp/generator/Microsoft.TypeSpec.Generator.ClientModel/test/Providers/MrwSerializationTypeDefinitions/AdditionalPropertiesTest.cs** - Added comprehensive deserialization test verifying all code aspects - Added comprehensive serialization test verifying all code aspects - Both tests validate complete generated code with detailed assertions **packages/http-client-csharp/generator/docs/backward-compatibility.md** - Added new section "AdditionalProperties Type Preservation" - Documents the object-to-BinaryData migration scenario - Provides examples of before/after code - Explains serialization/deserialization behavior differences - Formatted with prettier (removed trailing whitespace) ### Test Results ✅ - **1232/1232** Microsoft.TypeSpec.Generator.Tests PASSED - **1014/1014** Microsoft.TypeSpec.Generator.ClientModel.Tests PASSED - **10/10** AdditionalPropertiesTest tests PASSED - **2/2** Serialization backward compatibility tests with comprehensive assertions PASSED ### Comprehensive Test Coverage **Deserialization test verifies:** - Variable declaration: `IDictionary additionalProperties` - Dictionary initialization: `ChangeTrackingDictionary()` - Property enumeration: `foreach (var prop in element.EnumerateObject())` - Property name checks: `prop.NameEquals("name"u8)` - Type-specific methods: `GetString()` for known properties, `GetObject()` for additional properties - Constructor call with proper parameters **Serialization test verifies:** - Format validation and error handling - Property name serialization: `writer.WritePropertyName("name"u8)` - Property value serialization: `writer.WriteStringValue(Name)` - Foreach iteration over AdditionalProperties - Key serialization: `writer.WritePropertyName(item.Key)` - Value serialization: `writer.WriteObjectValue

Add support for 302 redirect #9497

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions