return error when parseLispTuple failed #570
Conversation
There was a problem hiding this comment.
Pull request overview
This PR enhances error handling in the ParseLispTuple and ParseLispTupleBigInt functions by returning errors when malformed input is encountered, rather than silently returning empty results. This change helps detect ABI mismatches or contract regressions earlier in the execution flow.
Changes:
- Modified
ParseLispTupleandParseLispTupleBigIntto returnerroras a second return value - Added
ErrMalformedLispTupleerror for invalid tuple structures - Updated all call sites to handle the new error return value
- Added comprehensive test cases for malformed input scenarios
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| pkg/ton/parser/parser.go | Added error returns to parsing functions with explicit validation and error propagation |
| pkg/ton/parser/parser_test.go | Extended test coverage with malformed input cases and error validation |
| pkg/ccip/bindings/router/reader.go | Updated to propagate parser errors through the decoder |
| pkg/ccip/bindings/onramp/reader.go | Updated to propagate parser errors through the decoder |
| pkg/ccip/bindings/offramp/reader.go | Updated to propagate parser errors through the decoder for both tuple types |
| pkg/ccip/bindings/feequoter/reader.go | Updated to propagate parser errors through the decoder |
| pkg/ccip/bindings/feequoter/fee_quoter.go | Added explicit error handling for parser results |
| deployment/ccip/1_6_0/sequences/fastcurse.go | Added explicit error handling with context-specific error message |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
pkg/ton/parser/parser.go
Outdated
| func ParseLispTupleBigInt(tuple []any) []*big.Int { | ||
| // Returns an error if the tuple structure is malformed (e.g., unexpected types), which can indicate | ||
| // ABI mismatches or contract regressions. An empty input tuple returns nil without error. | ||
| func ParseLispTupleBigInt(tuple []any) ([]*big.Int, error) { |
There was a problem hiding this comment.
Please work on deduplicating these two functions (same except the return type) or scope out a follow up ticket. Thx!
There was a problem hiding this comment.
@huangzhen1997 were you able to dedupe? I think @krebernisak was suggesting having a single function where maybe the return type is passed in as an arg and then the function switches on the return type when constructing the return val, but correct me if that's wrong @krebernisak
pkg/ton/parser/parser.go
Outdated
| for len(lispList) == 2 { | ||
| if bi, ok = lispList[0].(*big.Int); ok { | ||
| result = append(result, bi) | ||
| val, ok := lispList[0].(T) |
There was a problem hiding this comment.
Previously in both cases we cast to *big.Int, then take (map) bi.Uint64() when we want []uint64.
Now with generic we use it as parser.ParseLispTuple[uint64](r.AsTuple()) - will this work (against real network result)?
--
We can just do parser.ParseLispTuple[*big.Int](r.AsTuple()) and (again) map the result with bi.Uint64()
huangzhen1997
force-pushed
the
NONEVM-3627/return-error-when-parseLispTuple-failed
branch
2 times, most recently
from
ef6d94a to
479053c
Compare
| // Returns an error if the tuple structure is malformed (e.g., unexpected types), which can indicate | ||
| // ABI mismatches or contract regressions. An empty input tuple returns nil without error. | ||
| func ParseLispTuple(tuple []any) ([]uint64, error) { | ||
| func ParseLispTuple[T uint64 | *big.Int](tuple []any) ([]T, error) { |
There was a problem hiding this comment.
T here should be any of these (cell, slice, Int): https://github.com/xssnick/tonutils-go/blob/master/ton/runmethod.go as this will be a potential cast lispList[0].(T); - we can't cast to uint64, not a type ExecutionResult returns.
The way we do it is with custom code in this fn.
It would it better if this fn is general for the types ExecutionResult possibly returns, and we map to uint64 outside this fn.
There was a problem hiding this comment.
We can just do parser.ParseLispTuple*big.Int and (again) map the result with bi.Uint64()
Example using https://github.com/samber/lo
numbersBig := parser.ParseLispTuple[*big.Int](r.AsTuple())
numbers := lo.Map(numbersBig, func(x *big.Int, index int) string {
return x.Uint64();
})4 participants
No description provided.