fix: update test results fetching logic to support outcome validation…

[Dan Hellem (danhellem)]

This pull request refactors the logic for fetching and filtering Azure DevOps test results for a build, improving both the implementation and its test coverage. The main changes include switching from a grouped-results API to explicit paging over test runs and results, enforcing stricter schema validation for test outcome filters, and updating the tests accordingly to verify the new behavior and edge cases.

Refactor and optimization of test results fetching:

• The implementation for the test_results_from_build_id tool now fetches all test runs for a build and pages through their results directly, instead of relying on the grouped results API. This allows for more scalable and reliable result retrieval, especially for large builds.
• Paging and concurrency controls are added: results are fetched in pages of 1,000, and up to 5 test runs are processed concurrently to avoid overwhelming the API. [1] [2]

Schema and filtering improvements:

• The outcomes parameter is now strictly validated against the supported Azure DevOps test outcome values using a z.enum, preventing unsupported outcome values from being passed. [1] [2]
• Server-side filtering of test outcomes is now performed by mapping outcome strings to the appropriate enum values, ensuring accurate filtering.

Test suite updates and enhancements:

• The test suite for the tool has been rewritten to cover the new paging and concurrency logic, including: verifying correct API calls, handling of empty results, error handling, and enforcing the outcome schema.
• Tests now verify that unsupported outcome values are rejected, that all results are paged correctly, and that concurrency limits are respected.
• Error handling is improved and tested for both standard and non-standard error cases (e.g., API rejects with a non-Error value).

Dependency and import updates:

• Imports for Azure DevOps types and enums are updated to support the new implementation and tests. [1] [2]

GitHub issue number

#1682

Associated Risks

Changing response schema

✅ PR Checklist

• I have read the contribution guidelines
• I have read the code of conduct guidelines
• Title of the pull request is clear and informative.
• 👌 Code hygiene
• 🔭 Telemetry added, updated, or N/A
• 📄 Documentation added, updated, or N/A
• 🛡️ Automated tests added, or N/A

🧪 How did you test it?

Ran thru several simple manual tests and asked copilot to verify. Updated automated tests

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[GERALD MUDDLETHWACK (Paraphern)]

Contract-level pre-merge test done - full report in #1682 (#1682 (comment)). Short version: the branch builds and starts clean (44 tools pinned vs 40 in the 2.10.0 release, the 4 extra coming from main, nothing removed), and the only input-schema change on the target tool is outcomes becoming a 15-value enum - which matches the stricter validation described in this PR.

One release-note heads-up from that test: the enum silently rejects values the current release accepts (e.g. a lowercase failed), so agents or skills passing free-form strings will notice the upgrade.

The response fields themselves (testCaseTitle, errorMessage, stackTrace) need a live org with published test runs, which I can't provide from here - hoping someone with a real instance can confirm those before merge.