-
Notifications
You must be signed in to change notification settings - Fork 6
Open
Description
Problem
The version-dispatcher.ts and network-utils.ts modules lack comprehensive unit test coverage, which is critical for these core routing and utility functions.
Files to Test
1. src/network-utils.ts
Critical functions that need test coverage:
getCanonicalNetwork()- Network canonicalization logicgetNetworkDisplayName()- Network name resolutionisCanonicalNetwork()- CAIP-2 format validationgetCachedCanonicalNetwork()- Cached network lookupgetSupportedCanonicalNetworks()- Returns all supported networksgetSupportedHumanReadableNetworks()- Returns human-readable namesvalidateNetwork()- Network validation with error handlingdetermineX402Version()- Version detection from payload/bodyisVersionSupported()- Version support checking
2. src/version-dispatcher.ts
Critical class methods that need test coverage:
VersionDispatcher.verify()- Version routing for verify operationsVersionDispatcher.settle()- Version routing for settle operationsVersionDispatcher.verifyV1()- V1 verification implementationVersionDispatcher.verifyV2()- V2 verification implementationVersionDispatcher.settleV1()- V1 settlement implementationVersionDispatcher.settleV2()- V2 settlement implementationVersionDispatcher.isV1SettlementRouterMode()- SettlementRouter mode detection
Test Scenarios to Cover
network-utils.ts
-
Network Canonicalization
- Valid v1 names → v2 CAIP-2 identifiers
- Valid v2 CAIP-2 → passthrough
- Invalid networks → proper error messages
- Case sensitivity handling
- Cache functionality in
getCachedCanonicalNetwork()
-
Version Detection
- Version from paymentPayload.x402Version
- Version from body.x402Version
- Default to v1 when not specified
- Invalid version numbers → error
- Version support checking with/without FACILITATOR_ENABLE_V2 flag
-
Network Validation
- Empty/undefined network strings
- Non-string inputs
- Valid networks returning canonical keys
version-dispatcher.ts
-
Version Routing
- V1 requests route to v1 implementation
- V2 requests route to v2 implementation (when enabled)
- V2 requests rejected when disabled
- Metrics recording for each version/mode
-
SettlementRouter Mode Detection
- V1 with
extra.settlementRouter→ v1_settlementRouter mode - V1 without
extra.settlementRouter→ v1_standard mode - V2 always uses v2_router mode
- V1 with
-
Error Handling
- Unsupported versions return appropriate errors
- Invalid networks handled properly
- V2 facilitator not initialized errors
- Metrics recorded for errors
Acceptance Criteria
- Test files created:
test/unit/network-utils.test.tstest/unit/version-dispatcher.test.ts
- All critical functions/methods have test coverage
- Edge cases covered (invalid inputs, version mismatches, etc.)
- Mock external dependencies (v2 facilitator, pool manager, etc.)
- Coverage report shows >80% for both files
- All tests pass consistently
Priority
High - These are core modules for v1/v2 routing and need reliable test coverage
Technical Notes
- Use viem mocks for EVM-related tests
- Mock x402 package functions
- Mock @x402x/* package functions
- Test both with FACILITATOR_ENABLE_V2=true and false
- Verify metrics recording using spies/mocks
Metadata
Metadata
Assignees
Labels
No labels