fix: add validation to migrate_recipient_hashes function

[GazzyLee]

Issue

The migrate_recipient_hashes function in src/recipient_verification.rs migrates records to the new schema version without validating that existing records are well-formed. Corrupted records are silently carried over to the new schema, potentially causing issues downstream.

Solution

Added comprehensive validation checks during the migration process to detect and reject malformed entries early.

Changes

New Validation Functions

validate_recipient_hash_record(record: &RecipientHashRecord) -> Result<(), ContractError>

Validates the integrity of existing hash records before migration:

• Schema Version Check: Ensures schema version is reasonable (≤ 100)
• Corruption Detection: Rejects records with invalid schema versions that indicate data corruption
• Error Handling: Returns DataCorruption error for invalid records

validate_recipient_details(details: &RecipientDetails) -> Result<(), ContractError>

Validates new recipient details before storing migrated hashes:

• Wallet Validation: Addresses are validated implicitly via the Address type
• Bank Account Validation:
  • Rejects empty account numbers
  • Rejects empty routing codes
  • Enforces reasonable length limits (≤ 100 chars each) to detect corrupted strings
• Error Handling: Returns DataCorruption error for invalid details

Modified Functions

migrate_recipient_hashes()

Before:

• Silently migrated all records without validation
• Corrupted records would be carried over undetected

After:

• Calls validate_recipient_hash_record() on existing records
• Calls validate_recipient_details() on new details
• Returns DataCorruption error on validation failure (fail-fast approach)
• Prevents data corruption from propagating to the new schema
• Updated documentation with validation requirements

Benefits

✅ Data Integrity: Catches and rejects corrupted records during migration
✅ Fail-Fast: Stops migration immediately upon detecting malformed entries
✅ Clear Error Handling: Returns explicit DataCorruption error instead of silently proceeding
✅ Comprehensive Validation: Covers both existing records and new details
✅ Documented: Clear validation logic with comments explaining the checks

Testing Recommendations

• Test migration with valid records (should succeed)
• Test migration with corrupted schema versions (should return DataCorruption)
• Test migration with empty bank account numbers (should return DataCorruption)
• Test migration with empty routing codes (should return DataCorruption)
• Test migration with excessively long field values (should return DataCorruption)
• Test migration with valid wallet recipients
• Test migration with valid bank recipients

Breaking Changes

None. The function signature remains unchanged. Existing valid migrations will continue to work, but corrupted migrations will now fail with DataCorruption error instead of succeeding silently.

Related Issues

Fixes the data corruption vulnerability in recipient hash schema migration.

Checklist

• Branch created: fix/recipient-hash-validation
• Changes committed with clear message
• Code follows project conventions
• Documentation/comments added
• Tests added (awaiting test infrastructure)
• Build validated (pending resolution of pre-existing compilation errors)

Closes #614

[vercel]

@GazzyLee is attempting to deploy a commit to the Harold's projects Team on Vercel.

A member of the Team first needs to authorize it.

[drips-wave]

@GazzyLee Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits