Update qas

QA/python-0626.md

@@ -11,7 +11,7 @@ azure/ai/agents/aio/operations/_operations.py:4090: [R0914(too-many-locals), Age
 azure/ai/agents/aio/operations/_operations.py:4475: [R0914(too-many-locals), AgentsClientOperationsMixin.update_agent] Too many local variables (27/25)
 azure/ai/agents/aio/operations/_operations.py:4815: [R0914(too-many-locals), AgentsClientOperationsMixin.create_thread_and_run] Too many local variables (32/25)
 azure/ai/agents/aio/operations/_operations.py:26: [W0611(unused-import), ] Unused import urllib.parse
- 
+
 The _operations.py is straightly created by code gen.  Need advise how to fix them..
 
 ## answer
@@ -41,18 +41,24 @@ This should address the `too-many-locals` and `unused import urllib.parse` warni
 Hi Language - Python,
 Wondering why this pipeline is failing: https://dev.azure.com/azure-sdk/internal/_build/results?buildId=4959365&view=logs&j=447d33cb-e696-5bdf-6dab-daffaacae469
 The pr checks were successfull…
+```
+_ ERROR collecting sdk/healthinsights/azure-healthinsights-cancerprofiling/tests/test_cancer_profiling.py _
+ImportError while importing test module '/mnt/vss/_work/1/s/sdk/healthinsights/azure-healthinsights-cancerprofiling/tests/test_cancer_profiling.py'.
+Hint: make sure your test modules/packages have valid Python names.
+Traceback:
+.tox/mindependency/lib/python3.13/site-packages/azure/core/rest/__init__.py:27: in <module>
+    from ._rest_py3 import (
+.tox/mindependency/lib/python3.13/site-packages/azure/core/rest/_rest_py3.py:40: in <module>
+    from ._helpers import (
+.tox/mindependency/lib/python3.13/site-packages/azure/core/rest/_helpers.py:28: in <module>
+    import cgi
+E   ModuleNotFoundError: No module named 'cgi'
+```
 
 ## answer
-Your nightly/internal pipeline is failing due to a Python 3.13 error that’s been happening for the past couple months. The root cause is that `azure-healthinsights-cancerprofiling` specifies too old of a minimum version of `azure-core` for Python 3.13, where `cgi` was removed.
-
-Your PR checks passed because you only changed `azure-healthinsights-radiologyinsights`, and the pull request build is scoped to only that package. However, internal builds are service-wide, so they include all packages in the `healthinsights` folder, even those not being released. That's why the failure surfaced internally.
-
-To unblock you, I ran a build that artificially limits the build scope to only `azure-healthinsights-radiologyinsights`, which should allow you to release successfully.
-
-If `azure-healthinsights-cancerprofiling` is deprecated and not going to be released again, we should follow the deprecation process as outlined here:
-https://github.com/Azure/azure-sdk-for-python/blob/main/doc/deprecation_process.md
+Your PR checks passed because you only changed `azure-healthinsights-radiologyinsights`, and the `pull request` build is scoped to only that package. However, `internal` builds are service-wide, so they include all packages in the `healthinsights` folder, even those do not have a release stage. That's why the failure is only on the `internal` build.
 
-If we might need to release it again someday, we should fix the dependencies to keep it from falling into bitrot.
+To unblock you, please run a build that artificially limits the build scope to only `azure-healthinsights-radiologyinsights` by adding variable `BuildTargetingString` with value `azure-healthinsights-radiologyinsights`.
 
 # Testing SDK PRs
 
@@ -88,4 +94,3 @@ Once this PR passes:
 https://github.com/Azure/azure-sdk-for-python/pull/41724
 
 You can pull from main and try regenerating. Let me know if you see any diffs in regeneration and if these diffs work out for you.
-

QA/python-0703.md

@@ -37,7 +37,7 @@ The recommended approach is to create a custom error format class like:
 class BatchErrorFormat(ODataV4Format):
     # Custom parsing logic here
 ```
-Then, wrap the operation call like this:
+Then, wrap the operation calls like this:
 ```
 try:
    generated_client.op()
@@ -56,26 +56,22 @@ class BatchExceptionPolicy:
         except HttpResponseError as err:
             raise HttpResponseError(response=err.response, model=err.model, error_format=BatchErrorFormat) from err
 ```
-This policy can be injected once into the client constructor using per_call_policies, making it a scalable and maintainable solution. No new feature is needed for this—it’s supported today.
+Then inject the policy into the client constructor using `per_call_policies`: https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/core/azure-core/CLIENT_LIBRARY_DEVELOPER.md#pipeline
 
 # pipeline got stuck
 
 ## question 
 Hello,
-   I have a feature branch that won't be merged to main.   I just want to release it.   Before I do that, I want to make sure the pipeline is green.   But it is stuck currently.   Could someone help?
+I have a feature branch that won't be merged to main.  I just want to release it.  Before I do that, I want to make sure the pipeline is green. But it is stuck currently. Could someone help?
 [Feature/azure ai agents/1.0.2 by howieleung · Pull Request #41623 · Azure/azure-sdk-for-python](https://github.com/Azure/azure-sdk-for-python/pull/41623)
 
 ## answer
-If your pipeline is stuck and you're working from a feature branch that won't be merged to main, but you still want to release it, here's what you can do:
+You can simply run your internal release build against the release branch. If it reaches the "approve release" phase, you're good to go, it's actually more certain than if you got a PR build to run.
 
-First, although your PR has conflicts, you mentioned that rebasing isn't appropriate because the main branch contains the latest beta code, while your feature branch is for a stable release. In this case, you can simply run your internal release build against the release branch. If it reaches the "approve release" phase, you're good to go.
-
-You don’t have to approve a manually queued internal build, and this is consistent with how you've handled prior stable releases. Running the pipeline as a final check is understandable, even if not strictly required.
-
-If you're trying to maintain the PR build pattern, here's a recommended approach:
-
-Get your release branch to the desired state, excluding changelog and version updates.
-Submit a PR targeting your release branch that includes the changelog and version updates.
-The PR build will use the merge commit from both branches in the python - pullrequest pipeline, avoiding conflicts with main.
-Once merged, your release branch will be in its final state, and you can queue the release build.
-To clarify, the release build runs all the same tests plus a few more. If your goal is to validate the final public PR, this method works well with release branches.
+Yet if you want to maintain the PR build pattern. I do have a recommendation how you can make that work with release branches.
+
+1. Get your release branch where you want it to be minus `changelog` and `version` updates.
+2. Submit a PR targeting your release branch with the `changelog` and `version` updates. the PR build will use the merge commit from both your branches in the `python - pullrequest` pipeline, instead of hitting conflicts with `main`.
+3. Merge that. Your release branch will be in final state, which you can queue the release build for.
+
+To be clear, your release build will run all the same tests + a couple more, but if it's really about the last public PR then that's how you would do it with a release branch

QA/python-0710.md

@@ -2,7 +2,7 @@
 
 ## question 
 Hello Language - Python
- 
+
 I have code gen generated
 ```
 class AgentsClientOperationsMixin(
@@ -17,4 +17,4 @@ The AgentsClientOperationsMixin class should not be documented or publicly expos
 
 After discussion, the Python SDK team concluded that the correct solution is to make the mixin operation group a private class. This change ensures the class is hidden from public documentation while maintaining compatibility with the generated code.
 
-The issue has been tracked in https://github.com/microsoft/typespec/issues/7803, and the fix has been implemented in https://github.com/microsoft/typespec/pull/7817.
+The issue has been tracked in https://github.com/microsoft/typespec/issues/7803, and the fix has been implemented in https://github.com/microsoft/typespec/pull/7817.

QA/python-0717.md

@@ -1,8 +1,6 @@
-# API View Displays Incorrect Python Package Name
-
 ## question 
 Hi team,
- 
+
 I am generating the Python SDK api view for sdk review meeting. After I followed the instruction here to generate Python package: [What to do after generating the SDK code with codegen · Azure/azure-sdk-for-python Wiki](https://github.com/Azure/azure-sdk-for-python/wiki/What-to-do-after-generating-the-SDK-code-with-codegen#how-to-create-package). It generate a package name like this: **azure_ai_language_text-1.0.0b1-py3-none-any.whl**, with long suffix. And after uploading it to Api view, it still keep the same long name:
 `azure_ai_language_text-1.0.0b1-py3-none-any.whl`
 But I noticed that in the previous version api view, the Python namespace only show simplified verison like this :
@@ -11,26 +9,25 @@ Should I manually modify the package name before uploading it to api view, or is
 
 ## answer
 Hi, this is a bug in the parser and an issue is filed for it here. [[Python APIView\] manual uploads have the whl as the title name · Issue #10459 · Azure/azure-sdk-tools](https://github.com/Azure/azure-sdk-tools/issues/10459)
- 
+
 I'm currently working on fixing this. Is there a particular reason for the manual upload? Otherwise, you can auto-generate the APIView with the correct name by opening up a PR in the azure-sdk-for-python repo with the changes.
 
 # Python Live Test for async api
 
 ## question 
 Hello Language - Python,
- 
+
 We at Callautomation are working on adding live tests for the async APIs. When I tried to run a live test, I encountered an SSL certificate issue, as shown below. Could you help me understand what I might be missing?
- 
+
 ```
         except aiohttp.client_exceptions.ClientError as err:
 >           raise ServiceRequestError(err, error=err) from err
 E           azure.core.exceptions.ServiceRequestError: Cannot connect to host localhost:5001 ssl:True [SSLCertVerificationError: (1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate (_ssl.c:1028)')]
-```
-
+
 C:\Users\v-dharmarajv\AppData\Local\Programs\Python\Python313\Lib\site-packages\azure\core\pipeline\transport\_aiohttp.py:364: ServiceRequestError
+```
 
 ## answer
 You're encountering an SSL certificate error when running live tests for async APIs, specifically when connecting to https://localhost:5001. This is the test proxy endpoint, and the error is likely due to certificate verification failing. Although the same code works for another team member, the issue may be caused by environment variables — either missing or incorrectly set.
 
 To run live tests, make sure AZURE_TEST_RUN_LIVE is set to "true". If you also want to record, avoid setting AZURE_SKIP_LIVE_RECORDING. As a workaround for the SSL issue, set the environment variable PROXY_URL to http://localhost:5000 instead of using HTTPS. This bypasses certificate validation and resolves the issue.
-