Skip to main content

fix-random-ci-test-failure

Investigate and fix flaky/random CI test failures in dotnet/macios. Trigger on GitHub issues describing intermittent test failures, CI postmortem issues, or when asked to fix a flaky test. Analyzes test code, identifies root causes (shared state, environment dependencies, race conditions), and applies fixes.

소스 정보

저장소
dotnet/macios
최근 소스 활동
2026년 4월 30일 15:21
감지된 SKILL.md 언어
영어
스타
2,913
포크
578

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
fix-random-ci-test-failure
description
Investigate and fix flaky/random CI test failures in dotnet/macios. Trigger on GitHub issues describing intermittent test failures, CI postmortem issues, or when asked to fix a flaky test. Analyzes test code, identifies root causes (shared state, environment dependencies, race conditions), and applies fixes.
# Fix Random CI Test Failure Investigate and fix flaky CI test failures reported in GitHub issues for dotnet/macios. ## When to Use - User shares a GitHub issue about a flaky/intermittent test failure - Issue has the `ci-postmortem` label - User asks to fix a randomly failing test - Test failures appear across unrelated PRs (indicating environment-dependent flakiness) ## Workflow ### 1. Gather Failure Context Read the GitHub issue to extract: - **Test name** and **test suite** (e.g., monotouch-test) - **Error message** and **assertion failure details** - **Platform** (iOS, macOS, tvOS, Mac Catalyst) - **Affected builds** — check if failures span unrelated PRs (confirms flakiness vs. regression) If build URLs are provided, inspect logs for additional context (stack traces, timing info). ### 2. Locate and Analyze the Test Find the test source file: ``` grep -r "TestMethodName" tests/ ``` Read the **full test method** and all helper methods it calls. Understand: - What external resources does it use? (keychain, file system, network, simulators) - Does it use shared/hardcoded identifiers that could collide across parallel runs? - Does it properly clean up before and after execution? - Are there error paths that silently swallow failures? ### 3. Identify Root Cause Category Common flaky test root causes in this repo: #### Shared State / Resource Conflicts - **Symptom**: Test uses hardcoded identifiers (e.g., fixed keychain entries, file paths, port numbers) - **Fix**: Use process-unique identifiers (PID, GUID, bundle ID + test name) - **Reference**: `tests/monotouch-test/Security/KeyChainTest.cs` uses per-process unique IDs #### Environment-Dependent State - **Symptom**: Test depends on OS-level state (keychain, permissions, network availability) - **Fix**: Add robust setup/teardown, handle unexpected initial states, add retry logic for transient errors #### Unhandled Error Codes - **Symptom**: Code only handles expected success/failure codes, silently fails on unexpected ones - **Fix**: Add fallback handling for unexpected status codes, log diagnostic info #### Race Conditions / Timing - **Symptom**: Test passes locally but fails intermittently in CI - **Fix**: Add proper synchronization, increase timeouts, avoid timing-dependent assertions #### LAContext / Authentication Issues (Security tests) - **Symptom**: `InvalidRecord` or authentication-related errors on keychain operations - **Fix**: Only attach `LAContext` where actually needed (not on plain query/delete operations) ### 4. Apply the Fix When fixing: 1. **Prefer unique identifiers over shared ones.** Use `Process.GetCurrentProcess ().Id`, `Guid.NewGuid ()`, or `{bundleId}-{testType}-{pid}` patterns for resource identifiers. 2. **Create minimal query records.** For search/delete operations, don't attach unnecessary attributes (like `LAContext`) that can cause intermittent errors. 3. **Handle all status codes.** Never silently return `false` for unexpected error codes. Either handle them with a fallback path or fail with a descriptive assertion message. 4. **Add diagnostic logging.** Use `TestContext.Out.WriteLine` to log operation results that would help diagnose future failures. 5. **Clean up legacy state.** If renaming identifiers, also clean up entries from old names that may linger on CI agents. 6. **Always clean up in `finally` blocks.** Ensure test resources are released even on failure. ### 5. If the Fix is Unclear If you cannot determine the root cause with available information: 1. **Add diagnostic logging** to capture operation results (status codes, error details) in future failures. 2. **Log the initial state** at test start (e.g., does the resource already exist before the test runs?). 3. **Include all relevant status codes** in assertion failure messages. 4. Explain to the user what additional information the logging will provide and what hypotheses it will help test. ### 6. Create the PR - Branch naming: `dev/{username}/fix-{test-name}` or similar - Commit message should explain all root causes addressed - Reference the GitHub issue with `Fixes #NNNN` if the change actually fixes the problem, or `Ref #NNNN` if it only adds logging/diagnostics - Add the `copilot` label to the PR ## Key Patterns in This Repo - Keychain tests in `tests/monotouch-test/Security/` are particularly prone to flakiness due to shared macOS keychain state on CI agents - `InitSecRecord` in `RecordTest.cs` attaches `LAContext` to all `SecRecord` instances — this is sometimes unnecessary and can cause `InvalidRecord` errors - `KeyChainTest.cs` demonstrates the recommended pattern: per-process unique identifiers using bundle ID + test type + PID - Tests run on shared CI agent machines where leftover state from previous runs can cause interference
GitHub에서 보기