Merging this PR will not alter performance

✅ 12 untouched benchmarks

_{Comparing ai-bug-pipeline-9138-prevent-self-account-delete (1785f06) with stable (7298f33)¹}

Verdict: APPROVED

The replication test is realistic, correctly scoped, and confirmed to fail against the buggy code. It follows project testing conventions (no mocking, exact-match GraphQL error assertion, imports at the top, no issue references in test names).

A. Test realism

• CoreAccountDelete is a real generated mutation (confirmed in frontend/app/src/shared/api/graphql/generated/types.ts) so the operation name and data: {id: $id} shape match what real clients send.
• session_admin (backend/tests/component/conftest.py:2591) is constructed with account_id=create_test_admin.id, so passing create_test_admin.id as the deletion target genuinely exercises the self-deletion path the analyst described.
• All fixtures used in the signature (default_permission_backend, authentication_base, session_admin, create_test_admin) resolve to existing fixtures in backend/tests/conftest.py and backend/tests/component/conftest.py.

B. Test correctness

• The test asserts the expected behavior: result.errors is non-empty and the message equals "Cannot delete your own account". It does not codify the buggy behavior.
• It exercises the affected path identified by the analyst (InfrahubMutationMixin.mutate_delete in backend/infrahub/graphql/mutations/main.py), since CoreAccount falls through to the unguarded default mutation.
• The PR description includes a verified failure run against the unpatched code (AssertionError: assert None), confirming the test cannot pass without changing production code.

C. Test quality

• Imports are at the top (backend/tests/component/graphql/test_core_account.py:1-11), per dev/rules/testing-python.md.
• No unittest.mock/MagicMock/patch usage — uses real fixtures, consistent with the rest of test_core_account.py.
• GraphQL error message asserted with == (test_core_account.py:175), per the rule "Assert on the exact message with ==, not substring checks with in".
• CORE_ACCOUNT_DELETE is a module-level constant, mirroring how test_everyone_can_update_password defines its query inline — fine either way; the constant is reasonable for reuse.
• Test name test_admin_cannot_delete_own_account is descriptive and contains no issue number.
• Placement in backend/tests/component/graphql/test_core_account.py is consistent with the existing test_permissions and test_everyone_can_update_password cases targeting CoreAccount-related GraphQL behavior.

D. Alignment with analysis

• The test matches the analyst's primary root cause: the self-account deletion path through the default mutate_delete.
• Scope is intentionally narrow — the analyst's secondary finding (the apply_external_context bypass that overwrites account_session.account_id) is not covered. The PR body acknowledges this explicitly: "The test does NOT cover the context-override bypass path (that requires a separate test case once the original_account_id field exists)."
  • This is acceptable for the replication test, but the bypass path is a real gap. A follow-up test asserting that an external-context override cannot be used to bypass the self-delete guard should be added in the fix PR (not blocking).

Suggestions (non-blocking)

• Consider adding a complementary positive-case assertion (e.g., admin can delete a different account) in the same module, so a future regression that broadly breaks CoreAccountDelete is distinguishable from a regression that only breaks the self-delete guard. This is not required for replication.
• After the fix lands, add the bypass-path test the PR body alludes to, so the original_account_id/authenticating_account_id plumbing is exercised end-to-end.

Recommended next steps

• Approve this test and proceed to the fix phase.
• Track the bypass-path test as a follow-up so it is not forgotten once the fix introduces the new field on AccountSession.