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(frontend): use always Ledger canister for ICRC balances #5016

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

AntonioVentilii
Copy link
Collaborator

Motivation

To guarantee that the balance is always loaded and correct, we force the ICRC Wallet scheduler to always use the Ledger canister for the balance instead of the Index canister. This change could cause smaller lagged inconsistencies between data: the total of transactions may not match the balance for a few seconds.
However, it was deemed acceptable since it would at least guarantee the correct amount if the Index canister of an ICRC is not correctly working (it happened in a few cases and support tickets were raised).

Changes

  • Create new function getBalanceAndTransactions that merges the getBalance method with the transactions one. It will override the balance prop.
  • Use getBalanceAndTransactions in the IcWalletTransactionsScheduler.

Tests

Adjusted the tests to the new structure.

@AntonioVentilii AntonioVentilii requested a review from a team as a code owner March 4, 2025 09:51
@@ -87,7 +99,7 @@ const initIcrcWalletTransactionsScheduler = (): IcWalletTransactionsScheduler<
PostMessageDataRequestIcrcStrict
> =>
new IcWalletTransactionsScheduler(
getTransactions,
getTransactionsWithLedgerBalance,
Copy link
Member

Choose a reason for hiding this comment

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

Either before, ideally, or after, the code of the application should be refactored, as the schedulers and workers currently reflect the fact that we only fetch transactions—which, to some extent, is already not ideal.

So, IcWalletTransactionsScheduler, getTransactions, etc., should all be renamed to be more generic.

const getTransactionsWithLedgerBalance = async (
params: SchedulerJobParams<PostMessageDataRequestIcrcStrict>
): Promise<IcrcIndexNgGetTransactions> => {
const balance = await getBalance(params);
Copy link
Member

Choose a reason for hiding this comment

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

  • no await Promise.something([])?
  • what happens if the balance succeed and transactions fails, does that become acceptable since we are already here?

): Promise<IcrcIndexNgGetTransactions> => {
const balance = await getBalance(params);

// Ignoring the balance from the transactions' response.
Copy link
Member

Choose a reason for hiding this comment

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

We should be more expressive than just a comment in my opinion. This should be expressed by the code.

@@ -79,6 +79,18 @@ const getBalance = ({
});
};

const getTransactionsWithLedgerBalance = async (
params: SchedulerJobParams<PostMessageDataRequestIcrcStrict>
): Promise<IcrcIndexNgGetTransactions> => {
Copy link
Member

Choose a reason for hiding this comment

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

The return type isn't IcrcIndexNgGetTransactions. It's Omit<IcrcIndexNgGetTransactions, "balance"> & SomethingElse.

import { arrayOfNumberToUint8Array, jsonReplacer } from '@dfinity/utils';
import type { MockInstance } from 'vitest';
import { mock } from 'vitest-mock-extended';

describe('ic-wallet-transactions.worker', () => {
let spyGetBalance: MockInstance;
Copy link
Member

Choose a reason for hiding this comment

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

  • There is no new tests that asserts that the balance comes indeed from the ledger and not from the index?
  • No tests about one or the other failing?

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