A type representing a transaction (calldata) decoding. As you can see, these come in five types, each of which is documented separately.
This is a type for recording what decoding mode a given decoding was produced in. There are two decoding modes, full mode and ABI mode. In ABI mode, decoding is done purely based on the ABI JSON. Full mode, by contrast, additionally uses AST information to produce a more informative decoding. For more on full mode and ABI mode, see the notes on Decoding modes.
A type representing a log (event) decoding. As you can see, these come in two types, each of which is documented separately.
A type representing a returndata (return value or revert message) decoding. As you can see, these come in six types, each of which is documented separately.
If there are multiple possibilities, they're always returned in the order: return, revert, failure, empty, bytecode, unknownbytecode
Decodes the return data from a failed call.
The returned data, as a Uint8Array.
An array of possible decodings. At the moment it's impossible for there to be more than one. (If the call didn't actually fail, or failed in a nonstandard way, you may get no decodings at all, though!)
Decodings can either be decodings of revert messages, or decodings indicating that there was no revert message. If somehow both were to be possible, they'd go in that order, although as mentioned, there (at least currently) isn't any way for that to occur.
Generated using TypeDoc
Truffle Codec
This module provides low-level decoding and encoding functionality for Solidity and the Solidity ABI. Many parts of this module are intended primarily for internal use by Truffle and so remain largely undocumented, but some of its types are also output by @truffle/decoder, which provides a higher-level interface to much of this module's functionality.
If you're here from Truffle Decoder
If you're coming here from @truffle/decoder, you probably just want to know about the parts that are relevant to you. These are:
Note that the data category is largely scarce in documentation, although that's because it's largely self-explanatory.
If you're not just here from Truffle Decoder, but are actually interested in the lower-level workings, read on.
How this module differs from Truffle Decoder
Unlike Truffle Decoder, this library makes no network connections and avoids dependencies that do. Instead, its decoding functionality is generator-based; calling one of the decoding functions returns a generator. This generator's
next()function may return a finished result, or it may return a request for more information. It is up to the caller to fulfill these requests -- say, by making a network connection of its own. This is how @truffle/decoder works; @truffle/codec makes requests, and @truffle/decoder fulfills them by looking up the necessary information on the blockchain.This library also provides additional functionality beyond what's used by Truffle Decoder. In particular, this library also exists to support Truffle Debugger, and so it provides encoding functionality not just for transactions, logs, and state variables, but also for Solidity variables during transaction execution, including circularity detection for memroy structures. It includes functionality for decoding Solidity's internal function pointers, which the debugger uses, but which Truffle Decoder currently does not (although this is planned for the future).
There is also functionality for decoding return values and revert messages that goes beyond what's currently available in @truffle/decoder; this may get a better interface in the future.
How to use
You should probably use @truffle/decoder instead, if your use case doesn't preclude it. This module has little documentation, where it has any at all, and it's likely that parts of its interface may change (particularly regarding allocation). That said, if you truly need the functionality here, Truffle Decoder can perhaps serve as something of a reference implementation (and perhaps Truffle Debugger as well, though that code is much harder to read or copy).