Reaping vs. dusting and how to whitelist an account

Question

The following test can be used in the test suite of pallet-balances:

#[test]
fn reap_fails_but_account_gets_dusted() {
    ExtBuilder::default()
        .existential_deposit(2)
        .monied(true)
        .build()
        .execute_with(|| {
            assert_eq!(System::inc_providers(&1), frame_system::IncRefStatus::Existed);
            assert_eq!(System::providers(&1), 2);
            assert_eq!(Balances::free_balance(1), 20);
            assert_ok!(<Balances as Currency<_>>::transfer(&1, &2, 19, AllowDeath));
            assert!(System::account_exists(&1));
            assert_eq!(Balances::free_balance(1), 0);
            assert_eq!(System::providers(&1), 1);
        });
}

What we see here is that the account is not reaped in the sense that it still exists, but it does get dusted. This seems to contradict info I got on GitHub, but maybe I'm just reading this wrong (https://github.com/paritytech/polkadot-sdk/issues/227). The docs also say that reference counters prevent the account from being reaped. So I'm starting to get the impression that reaping and dusting are two completely separate processes.

The questions are:

1. Is the behavior above expected or is this a bug?
2. Are reaping and dusting separate processes?
3. How can I whitelist an account in pallet-balances to prevent it from getting dusted?

Edit. I may have misread some of the docs. So apparently we can use consumers to make the transfer error. Doesn't answer any of the questions though.

Answer 1

Are reaping and dusting separate processes?

Yes, this made it clear to me:

• dusting: removing remaining balance (e.g. after a transfer) if it is lower than the ED.
• reaping: removing an account from storage.

How can I whitelist an account in pallet-balances to prevent it from getting dusted?

I don't think that is currently possible. There is no way to prevent this other than setting no ED or having free_balance + reserved_balance > ED(ref). However, if you call transfer with Preservation::Preserve in stead of Preservation::Expendable, it will fail (ref).

Is the behavior above expected or is this a bug?

From reading the README:

No account should ever have a total balance that is strictly between 0 and the existential deposit (exclusive). If this ever happens, it indicates either a bug in this module or an erroneous raw mutation of storage.

Which in the test case you did, you increased the providers. So I think it is the expected behaviour.