ICRC-1 transfer errors

Is there a detailed description of the errors in

type TransferError = variant {
    BadFee : record { expected_fee : nat };
    BadBurn : record { min_burn_amount : nat };
    InsufficientFunds : record { balance : nat };
    TooOld;
    CreatedInFuture: record { ledger_time : Timestamp };
    Duplicate : record { duplicate_of : nat };
    TemporarilyUnavailable;
    GenericError : record { error_code : nat; message : text };
};

What exactly do they mean and in what situations can they arise? For example, what defines a duplicate? And which situations fall under TemporarilyUnavailable?

My second question is about upgradability. Can an implementation add variants to this? My understanding is that it can not because that would create a supertype in a return type and general ICRC-1 clients wouldn’t be able to interact with that implementation. How do we deal with this? I expect that implementations can have idiosyncratic errors.

4 Likes

Any ideas?

I suppose as the list can’t be extended that we have to use GenericError. Different ledger implementations just have to agree on what the error codes in GenericError mean. Conflicting behaviour would be bad for clients. We’ll have to track these error codes somewhere publicly.

I think the idea was to use generic error going forward. Probably these should have been similar to metadata and been more extensible.