Report parameter type annotation changes in breaking_changes_checker

[Copilot]

The breaking-changes tool silently ignored parameter annotation changes (e.g. tag_map: Optional[str] → tag_map: Optional[Dict[str, List[str]]]). run_parameter_level_diff_checks only branched on default and param_type (parameter kind), so diffs on the type field produced by create_parameters were dropped.

Changes (scripts/breaking_changes_checker/)

• breaking_changes_tracker.py
  • New enum member BreakingChangeType.CHANGED_PARAMETER_TYPE and message templates CHANGED_PARAMETER_TYPE_MSG / CHANGED_PARAMETER_TYPE_OF_FUNCTION_MSG.
  • Handle diff_type == "type" in run_parameter_level_diff_checks, dispatching to new check_parameter_annotation_type_changed (mirrors the existing kind check; emits stable→current annotation strings).
  • Normalize a missing parameter annotation (Python None, as produced by create_parameters when arg.annotation is None) to the distinct display string <no annotation>, so it can be disambiguated from an explicit None annotation (stored as the string "None") in the reported message.
• README.md — add ChangedParameterType row to the breaking-change categories table.
• tests/test_breaking_changes.py
  • test_parameter_annotation_type_changed covers both class-method and module-function cases, including the Optional[str] → Optional[Dict[str, List[str]]] scenario from the issue.
  • test_parameter_annotation_type_missing_vs_explicit_none covers the missing-vs-explicit None annotation disambiguation.

Example output

(ChangedParameterType): Method `EffectiveNetworkSecurityGroup.__init__` changed type of its parameter `tag_map` from `Optional[str]` to `Optional[Dict[str, List[str]]]`
(ChangedParameterType): Function `my_func` changed type of its parameter `a` from `<no annotation>` to `str`
(ChangedParameterType): Function `my_func` changed type of its parameter `b` from `None` to `int`

Notes

• ChangelogTracker inherits this via super().run_checks() — no additional wiring needed.
• Existing test data has no parameter-level type diffs, so current expectations are unaffected. Reviewers may want to consider whether an azure-mgmt-* allowlist entry is desirable given regeneration churn.

[Copilot]

Pull request overview

Updates the breaking-changes checker to report parameter type annotation changes (previously dropped), ensuring signature annotation diffs are surfaced as breaking changes.

Changes:

• Add a new breaking-change category ChangedParameterType with corresponding message templates.
• Detect "type" diffs in run_parameter_level_diff_checks and emit the new breaking-change record.
• Document the new category in the tool README and add tests covering method + module-level function cases.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
scripts/breaking_changes_checker/breaking_changes_tracker.py	Adds ChangedParameterType and emits breaking changes when a parameter’s annotation string changes.
scripts/breaking_changes_checker/README.md	Documents ChangedParameterType in the breaking-change categories table.
scripts/breaking_changes_checker/tests/test_breaking_changes.py	Adds coverage ensuring annotation type changes are reported for both methods and functions.

[Copilot]

Just as a heads up, I was blocked by some firewall rules while working on your feedback. Expand below for details.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• pypi.org
  • Triggering command: /home/REDACTED/work/azure-sdk-for-python/azure-sdk-for-python/.venv/bin/pip /home/REDACTED/work/azure-sdk-for-python/azure-sdk-for-python/.venv/bin/pip install jsondiff (dns block)
• scanning-api.github.com
  • Triggering command: /home/REDACTED/work/_temp/ghcca-node/node/bin/node /home/REDACTED/work/_temp/ghcca-node/node/bin/node --enable-source-maps /home/REDACTED/work/_temp/copilot-developer-action-main/dist/index.js (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[msyyc]

Pass test locally and pls take a review. @catalinaperalta

[catalinaperalta]

The changes lgtm, I did wonder if we could implement it as an independent checker like the ones found under this directory: https://github.com/Azure/azure-sdk-for-python/tree/main/scripts/breaking_changes_checker/checkers I wouldnt block on it if it's too complicated

[msyyc]

The changes lgtm, I did wonder if we could implement it as an independent checker like the ones found under this directory: https://github.com/Azure/azure-sdk-for-python/tree/main/scripts/breaking_changes_checker/checkers I wouldnt block on it if it's too complicated

@catalinaperalta I make a rough estimation then find it may need some refactor if implement same logic in checkers. So I hope we could keep current design then refactor it if needed in another PR.

[catalinaperalta]

The changes lgtm, I did wonder if we could implement it as an independent checker like the ones found under this directory: https://github.com/Azure/azure-sdk-for-python/tree/main/scripts/breaking_changes_checker/checkers I wouldnt block on it if it's too complicated

@catalinaperalta I make a rough estimation then find it may need some refactor if implement same logic in checkers. So I hope we could keep current design then refactor it if needed in another PR.

Do you mean because you'd have to do more parsing to get back down to the parameter type?

[msyyc]

The changes lgtm, I did wonder if we could implement it as an independent checker like the ones found under this directory: https://github.com/Azure/azure-sdk-for-python/tree/main/scripts/breaking_changes_checker/checkers I wouldnt block on it if it's too complicated

@catalinaperalta I make a rough estimation then find it may need some refactor if implement same logic in checkers. So I hope we could keep current design then refactor it if needed in another PR.

Do you mean because you'd have to do more parsing to get back down to the parameter type?

Yes.