Include error-message as part of the GET/LIST endpoints to help with troubleshooting

[sabbyanandan]

As a user, when the actively observing chainhooks fail to trigger either because of the errors in Chainhook itself or due to the issues when triggering the HTTP endpoint for a given event, I would like to know what and why it failed, so I can troubleshoot and course-correct.

The interruptions could be:
a: Errors in Chainhook
b: Having an incorrect HTTP endpoint as a trigger
c: Having an unresponsive or erroring HTTP endpoint as a trigger
d: Any runtime errors between the Chainhook node, Chainhook API, or HTTP endpoints

If we can include the error-message and can define a category for those errors, the Hiro Platform can handle them and gracefully let users know of the problem.

[MicaiahReid]

@lgalabru I'm wondering if we can store any errors that occur in checking or triggering a predicate and return them with PredicateStatus

[MicaiahReid]

Upon further investigation, we already store and return errors when evaluating a predicate:

chainhook/components/chainhook-cli/src/service/runloops.rs

Line 67 in d688bcb

let status = PredicateStatus::Interrupted(format!(

@BLuEScioN / @sabbyanandan - whenever the predicate status is "Interrupted", it will include an error. Do you think that will be sufficient for the platform to display more info to the user?

[sabbyanandan]

Woah! Awesome, I think this should suffice. Now, if we are able to trigger those errors, we can see how much of the information is floating through the pipes, and how we may want to massage them for the end-users. As far as the "caused by" or equivalent is clearer, that is all it matters to the end users.

[smcclellan]

@sabbyanandan If I'm following here, this issue is a no-op since we already surface the errors? Can it be closed?

[sabbyanandan]

@smcclellan: Before you close it, perhaps you can verify the functionality and share the sample JSON responses with the error messages. That way @BLuEScioN can review the JSON and explore how to further handle it gracefully for the end-users with the help of @andromeda995.

cc: @andresgalante

[MicaiahReid]

I've added some additional errors in #397

[MicaiahReid]

Here are the possible errors:

• Unable to evaluate predicate on Stacks chainstate: {e}. e will have the following options:
  • Chainhook specification must include fields 'start_block' when using the scan command
  • Unable to retrieve block {current_block_height}
  • Unable to retrieve block {current_block_height}: {e}
  • Scan aborted (consecutive action errors >= 3): {e}. e will have some further reasons on why:
    • unable to build http client: {e}
    • unable to serialize payload {e}
    • unable to send request after several retries. most recent error: Trigger {url} failed with status {http_post_status}
    • unable to create file {file_name}: {e}
    • unable to retrieve current_dir: {e}
    • unable serialize bytes as utf8 string {e}
    • unable to open file {e}
• Unable to evaluate predicate on Bitcoin chainstate: {e}. e will have the following options:
  • Bitcoin RPC error: {e}
  • Bitcoin chainhook specification must include a field start_block in replay mode
  • unable to retrieve Bitcoin chain tip ({e})
  • Scan aborted (consecutive action errors >= 3): {e}. e will have some further reasons on why:
    • unable to build http client: {e}
    • unable to serialize payload {e}
    • unable to send request after several retries. most recent error: Trigger {url} failed with status {http_post_status}
    • unable to create file {file_name}: {e}
    • unable to retrieve current_dir: {e}
    • unable serialize bytes as utf8 string {e}
    • unable to open file {e}

[sabbyanandan]

@MicaiahReid: Thanks.

@LakshmiLavanyaKasturi: Something to summarize in the Chainhook docs, perhaps under the error handling guide or similar.

[github-actions]

🎉 This issue has been resolved in version 1.1.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀