Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(error-handling): add canister error tracking for query and update calls #6443

Closed
wants to merge 1 commit into from

Conversation

yhabib
Copy link
Contributor

@yhabib yhabib commented Feb 17, 2025

Motivation

We want to track canister errors to update the UI accordingly. This PR builds on #6418 and adds a wrapper to our existing queryAndUpdate function to monitor errors during query or update calls.

The follow-up will use this store to adjust how we display failed balances when the ledger canister is down for the Portfolio and Tokens pages.

Changes

  • Adds a wrapper for queryAndUpdate that monitors issues with the requested canister.

Tests

  • Adds unit tests for the wrapper's new behavior.

Todos

  • Add entry to changelog (if necessary).
    Not necessary

@yhabib yhabib marked this pull request as ready for review February 17, 2025 17:42
@yhabib yhabib requested a review from a team as a code owner February 17, 2025 17:42
identity,
}) => {
if (!isQueryCallOfAQueryAndUpdateCall(strategy, certified))
canistersErrorsStore.set({ canisterId, rawError: error });
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not every error is an indication that there's something wrong with the canister.

The best example I can think of is that the ckBTC minter, when you request completed transactions, if there are no completed transactions, it will throw an error which includes pending transactions:

if (!(error instanceof MinterNoNewUtxosError)) {

This is how we fetch completed and pending transactions. This is normal operations and doesn't indicate that there's anything wrong with the canister or the request.

Probably there are other (perhaps less clear cut) cases where we might get an error from a canister but not want to put it in this store.

@yhabib
Copy link
Contributor Author

yhabib commented Feb 20, 2025

Closing in favor of a less intrusive approach

@yhabib yhabib closed this Feb 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants