fix: implement retry logic for creating test suites to handle concurr…

[danhellem]

This pull request introduces a retry mechanism with exponential backoff for handling concurrency conflicts when creating a child test suite in the configureTestPlanTools function. This makes the process more robust and resilient to transient errors caused by concurrent updates.

Improvements to error handling and reliability:

• Added a retry loop (up to 5 attempts) with exponential backoff and jitter when a concurrency conflict error is detected during the creation of a child test suite in src/tools/test-plans.ts. This helps mitigate issues caused by simultaneous updates from multiple users or processes. [1] [2]
• Enhanced error messaging by returning a specific error if the maximum number of retries is exceeded.

GitHub issue number #839

Associated Risks

None

✅ 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?

Tested manually and re-ran automated tests

[github-actions]

Dependency Review

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

Scanned Files

None

[Copilot]

Pull request overview

This pull request adds retry logic with exponential backoff to handle concurrency conflicts when creating test suites in Azure DevOps. The enhancement addresses transient errors caused by simultaneous updates from multiple users or processes.

Changes:

• Added retry mechanism with exponential backoff and jitter for the create_test_suite tool to handle concurrency conflicts
• Implemented error detection for specific Azure DevOps concurrency error codes (TF26071)
• Enhanced error messaging for maximum retry scenarios

[Copilot]

The concurrency error detection logic uses string matching on error messages, which is fragile and may break if error message formats change. Consider checking if the error object has specific error codes or types that can be used for more reliable error classification. If the Azure DevOps API provides structured error codes, use those instead of string matching.

Suggested change

	// Check if it's a concurrency conflict error
	const isConcurrencyError = errorMessage.includes("TF26071") || errorMessage.includes("got update") || errorMessage.includes("changed by someone else");
	// Prefer structured error information when available
	const typedError = error as { statusCode?: number; code?: string; message?: string };
	const statusCode = typeof typedError?.statusCode === "number" ? typedError.statusCode : undefined;
	const errorCode = typeof typedError?.code === "string" ? typedError.code : undefined;
	// Check if it's a concurrency conflict error
	const isConcurrencyError =
	statusCode === 409 || // HTTP 409 Conflict
	errorCode === "ConcurrencyConflictException" || // Azure DevOps concurrency error code (if provided)
	errorMessage.includes("TF26071") ||
	errorMessage.includes("got update") ||
	errorMessage.includes("changed by someone else");

[Copilot]

@danhellem I've opened a new pull request, #845, to work on those changes. Once the pull request is ready, I'll request review from you.