Responsive panic about invalid user input during contract execution #138

New issue

Open

opened 2025-12-28 18:08:39 +00:00 by sami · 2 comments

sami commented

2025-12-28 18:08:39 +00:00

Owner

Originally created by @cthulhu-rider on GitHub (Apr 10, 2023).

Context

Calling https://pkg.go.dev/github.com/nspcc-dev/neofs-contract/container#SetEACL threw following exception:

contract execution finished with state FAULT; exception: at instruction 3702 (SUBSTR): invalid offset

This behavior occurs similar to index out of range panic in the general Go view. While in general panic has the right to exist (developer's mistakes), code MUST NOT panic about user input.

Solution

Explore all methods which are sensitive to user input and

document all input restrictions for all methods (see also #323)
check correctness of the user input in code (this prevents all undesired panics) and return responsive errors

Originally created by @cthulhu-rider on GitHub (Apr 10, 2023). ## Context Calling https://pkg.go.dev/github.com/nspcc-dev/neofs-contract/container#SetEACL threw following exception: ``` contract execution finished with state FAULT; exception: at instruction 3702 (SUBSTR): invalid offset ``` This behavior occurs similar to `index out of range` panic in the general Go view. While in general panic has the right to exist (developer's mistakes), code MUST NOT panic about user input. ## Solution Explore all methods which are sensitive to user input and * document all input restrictions for all methods (see also #323) * check correctness of the user input in code (this prevents all undesired panics) and return responsive errors

sami added the

bug

documentation

labels

2025-12-28 18:08:39 +00:00

sami commented

2025-12-28 18:08:39 +00:00

Author

Owner

@roman-khimov commented on GitHub (Apr 10, 2023):

code MUST NOT panic about user input

For a contract it's OK to panic.

check correctness of the user input in code (this prevents all undesired panics) and return responsive errors

You're assuming that contracts can return (any, error), but they can't. The VM only supports one return value from public methods and either it becomes a struct{} with two fields, but this complicates the interfaces substantially and can't be handled in a generic way, or contract just panics which is an exception that in most cases leads to FAULT.

Documenting assumptions on inputs is OK, it's useful anyway.

@roman-khimov commented on GitHub (Apr 10, 2023): > code MUST NOT panic about user input For a contract it's OK to panic. > check correctness of the user input in code (this prevents all undesired panics) and return responsive errors You're assuming that contracts can return `(any, error)`, but they can't. The VM only supports one return value from public methods and either it becomes a `struct{}` with two fields, but this complicates the interfaces substantially and can't be handled in a generic way, or contract just panics which is an exception that in most cases leads to FAULT. Documenting assumptions on inputs is OK, it's useful anyway.

sami commented

2025-12-28 18:08:39 +00:00

Author

Owner

@cthulhu-rider commented on GitHub (Apr 10, 2023):

@roman-khimov by

return responsive errors

I meant responsive exceptions (in Go code - panic arg). IMO it's clearer to receive missing X field fault exception than invalid offset.

@cthulhu-rider commented on GitHub (Apr 10, 2023): @roman-khimov by > return responsive errors I meant responsive exceptions (in Go code - `panic` arg). IMO it's clearer to receive `missing X field` fault exception than `invalid offset`.