Debugging
How to debug TinyChain code
There is an interactive debugger planned but the current debugging experience relies entirely on naming and logging. Consider this example:
Running this produces a BadRequest
. This program is small enough that it's easy to search for "foo," but in larger programs the auto-generated names for intermediate variables can be very unhelpful when debugging.
Step 1: assign descriptive names
The first step to take in situations like this is to explicitly assign names in the Op
context:
Running this produces a slightly more helpful error message: {'/error/bad_request': 'while resolving result: while resolving b: not a Number: foo'}
. Now you can at least tell that the error is happening with TinyChain tries to resolve state b
.
Another reason why it's important to assign names to the individual states in an Op
is to make sure that each step of your program is only executed once. For example:
In the case above updated
is a flow control, not a State
, so it will be executed again every time it's referenced. Assigning a name solves this problem:
In this case, we've assigned the result of x.write(x + 1)
the name update
, so each reference to cxt.update
will resolve the result of updating x, not the update op itself.
Step 2: add validation
The simplest way to inspect the state of a running TinyChain program is to add validation checks. For example:
In this case you'll get a divide-by-zero error if x
is zero-valued, but it may be confusing in the context of a larger program because you won't necessarily know where the error is happening. To get more information, you can add validation checks to your code:
Step 3: turn on logging
In larger programs, it may unclear which Op
you need to inspect to begin with. To make this determination, you can turn on debug logging:
With debug logging on, you should see some helpful debug output when you run your test script:
As long as you have at least a few descriptive names explicitly set, this should give you a good idea where to look for more fine-grained debugging. You can also explicitly use logging.debug
in your code to get information about the state of the program at compile-time.
Step 4: inspect program code as JSON
If steps 1-3 don't help, or you suspect you may have found a bug in TinyChain itself, the final step to try on your own is to inspect the compiled JSON that's actually executed by a TinyChain host.
When you run this, you'll see the structure of your program represented as JSON printed to stdout:
See technical details for the specification of the subset of JSON which TinyChain uses as an application language.
Step 5: ask for help
If steps 1-4 didn't solve your problem, please email support@tinychain.net or open an issue!
Step 6: run the host in debug mode
The TinyChain host supports extensive debug logging, but for performance reasons it must be compiled in debug mode in order to enable this logging. If you're running TinyChain in a Docker container, you'll have to open an interactive terminal:
Now, whenever you make a request to your local host, you'll see the host's internal debug logs in the terminal.
Last updated