Regenerate AzureIoTCentral from the type-identity generator fix - #225
Merged
Conversation
The generator stripped version affixes from definition names without knowing which definitions a connector retains, so DeviceV1 and DeviceV2 both wanted to be Device and only one was emitted. The shipped Device carried DeviceV1 seven properties, and the organizations property that DeviceV2 declares was unreachable from the SDK. The connector now exposes DeviceV1 and DeviceV2 as distinct models, so callers of the v2 routes can read every field the service returns. This is the demonstrating client for the paired generator change; the fix affects five SDK clients in total and the remaining four are left to the full regeneration that is already owed.
hallvictoria
approved these changes
Jul 30, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Regenerates
AzureIoTCentralfrom the paired generator fix in AzureUX-BPM PR 16618864.What was wrong
The generator strips a version affix when turning a swagger definition name into a type name, so
DeviceV1andDeviceV2both wanted to beDevice. When a connector retains both, only one type was emitted and the other was dropped silently.azureiotcentralshipped the consequence: a singleDeviceclass carryingDeviceV1's seven properties, whileDeviceV2declares eight. Theorganizationsproperty the service returns on the v2 routes was unreachable from the SDK.What changes here
DevicebecomesDeviceV1andDeviceV2, emitted as distinct models, so callers of the v2 routes can read every field.This is a breaking rename for anyone referencing
Deviceon this connector, which is the point: the previous name silently mapped to only one of two contracts.Scope note
The diff is larger than this one fix. The checked-in generated clients predate several merged generator changes, so regenerating any client also picks up that accumulated drift. Of the change here, +204 lines are attributable to the type-identity fix; the rest is drift that a full regeneration would have carried anyway.
The generator fix affects five SDK clients —
AzureAD,AzureIoTCentral,Office365,Pipedrive,Planner. This PR carries onlyAzureIoTCentralas the demonstrating client, since it holds the headline defect. The other four are left to the full regeneration already owed.Validation
dotnet buildsucceeds, 912 SDK tests pass.IPageable<Device>was emitted against a class now namedDeviceV1. Generation success alone would have shipped code that does not build.Authored with Dobby agent.