🐛 Fix mutation name collision causing parameter validation errors

[evoludigit]

Summary

Fixes a critical bug where mutations with similar names (e.g., CreateItem and CreateItemComponent) were causing parameter validation confusion. The createItemComponent mutation would incorrectly require item_serial_number from CreateItemInput instead of its own CreateItemComponentInput fields.

Root Cause

The resolver naming strategy used to_snake_case(class_name) which could create collisions when similar class names produced similar snake_case names. This caused one mutation to overwrite another's metadata in the GraphQL schema registry, leading to incorrect parameter validation.

Solution

• Unique Resolver Naming: Use PostgreSQL function names for resolver naming to ensure uniqueness (e.g., create_item vs create_item_component)
• Fresh Annotations: Create new annotation dictionaries for each resolver to prevent shared references
• Comprehensive Testing: Add extensive tests to verify the fix and prevent regressions

Changes

• Modified: src/fraiseql/mutations/mutation_decorator.py - Updated resolver naming logic
• Added: tests/integration/graphql/mutations/test_similar_mutation_names_collision_fix.py - Comprehensive test coverage

Impact

• ✅ Mutations with similar names now work independently with correct validation
• ✅ No breaking changes - existing functionality preserved
• ✅ Enhanced test coverage for mutation name collision scenarios

Test plan

• All existing mutation tests pass (221 tests)
• New collision-specific tests pass (8 tests)
• Integration tests verify independent mutation behavior
• Parametric tests ensure correct metadata for each mutation

Fixes the bug reported in /tmp/fraiseql_bug_report.md.

🤖 Generated with Claude Code