Currently, client exception verification depends on exception mappers defined as Python source within execution-specs, for example:
|
class EthrexExceptionMapper(ExceptionMapper): |
|
"""Ethrex exception mapper.""" |
|
|
|
mapping_substring = { |
|
BlockException.INVALID_GASLIMIT: ( |
|
"Gas limit changed more than allowed from the parent" |
|
), |
|
TransactionException.TYPE_3_TX_MAX_BLOB_GAS_ALLOWANCE_EXCEEDED: ( |
|
"Exceeded MAX_BLOB_GAS_PER_BLOCK" |
|
), |
This creates friction for client teams and STEEL as any change in exception message strings requires a PR to execution-specs. This friction could be eliminated if we allow clients to define exception mappers in their own repo (as one of toml/yaml/json) and enable import of these files to populate our exception mappers.
Additionally,m #2622 enables exception mapping for state, blockchain and blockchain engine test fixtures. Imo, now is the time to move the primary test approach from hive (system) to module testing. In which case, clients can run these tests on every push in CI. This means, if we keep the status quo, client teams would need to PR to execution-specs in order to fix exceptions, which is clearly unacceptable. Allowing clients to enable their own exception mappers would greatly simplify this process.
h/t @edg-l who originally made this suggestion!
Currently, client exception verification depends on exception mappers defined as Python source within execution-specs, for example:
execution-specs/packages/testing/src/execution_testing/client_clis/clis/ethrex.py
Lines 10 to 19 in 4bf8bbe
This creates friction for client teams and STEEL as any change in exception message strings requires a PR to execution-specs. This friction could be eliminated if we allow clients to define exception mappers in their own repo (as one of toml/yaml/json) and enable import of these files to populate our exception mappers.
Additionally,m #2622 enables exception mapping for state, blockchain and blockchain engine test fixtures. Imo, now is the time to move the primary test approach from hive (system) to module testing. In which case, clients can run these tests on every push in CI. This means, if we keep the status quo, client teams would need to PR to execution-specs in order to fix exceptions, which is clearly unacceptable. Allowing clients to enable their own exception mappers would greatly simplify this process.
h/t @edg-l who originally made this suggestion!