-
Notifications
You must be signed in to change notification settings - Fork 13
refactor: operations parsing refak #649
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
d43ec40 to
1fcd95f
Compare
✅ Preprod Tests: PASSEDTests run against preprod network with live blockchain data |
✅ Preprod Tests: PASSEDTests run against preprod network with live blockchain data |
6c73dba to
f02b569
Compare
✅ Preprod Tests: PASSEDTests run against preprod network with live blockchain data |
✅ Preprod Tests: PASSEDTests run against preprod network with live blockchain data |
f02b569 to
83ad587
Compare
✅ Preprod Tests: PASSEDTests run against preprod network with live blockchain data |
1 similar comment
✅ Preprod Tests: PASSEDTests run against preprod network with live blockchain data |
83ad587 to
6b2f28a
Compare
Remove duplicate dRepVoteDelegation operations from integration test golden files. These duplicates were appearing due to the certificate processing logic creating operations twice. This fix aligns with the TransactionOperationParser refactoring that properly handles DRep vote delegation certificates.
6b2f28a to
45c05cd
Compare
invariants Fixed 4 failing /construction/parse golden tests that had duplicate operations at index 3. Tests expected 5 operations but API correctly returned 4. Added operation invariant tests to prevent ordering bugs: - assert_operations_ordered() - ensures operations sorted by index - assert_operations_sequential() - ensures indices [0, 1, 2, ...] Covers /search/transactions, /block, and /block/transaction endpoints. This would have caught the bug where /construction/parse returns operations in processing order (inputs → outputs → certs → withdrawals) instead of sorted by operation_identifier.index.
|
I fixed the other failing tests but found a small issue with the The API is returning operations in the order they were processed (inputs → outputs → certs → withdrawals), but the test expects them sorted by their uv run tests/integration/test_construction_api.py -u http://localhost:8082 "parse/complex_transactions/withdrawal_with_drep_delegation.json"Expected: Array ordered by index [0, 1, 2, 3] {
"operations": [
{ "operation_identifier": { "index": 0 }, "type": "input", ... },
{ "operation_identifier": { "index": 1 }, "type": "output", ... },
{ "operation_identifier": { "index": 2 }, "type": "withdrawal", "amount": {...}, ... },
{ "operation_identifier": { "index": 3 }, "type": "dRepVoteDelegation", ... }
]
}Actual: Array ordered [0, 1, 3, 2] {
"operations": [
{ "operation_identifier": { "index": 0 }, "type": "input", ... },
{ "operation_identifier": { "index": 1 }, "type": "output", ... },
{ "operation_identifier": { "index": 3 }, "type": "dRepVoteDelegation", ... },
{ "operation_identifier": { "index": 2 }, "type": "withdrawal", "amount": {...}, ... }
]
}The test fails because it accesses We just need to sort the operations list by index before returning it. |
- Sort operations by operation_identifier.index before returning from getOperationsFromTransactionData() to ensure consistent ordering (0, 1, 2, ...) - Add OperationOrdering test class with shouldReturnOperationsSortedByIndex test to verify sorting behavior 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
No description provided.