Have SubtensorModule::TotalIssuance track extrinsic fees

[camfairchild]

Describe the bug

The pallet_subtensor::migrations::migrate_init_total_issuance::initialise_total_issuance migration is seemingly running every time there is a runtime upgrade. Also running every upgrade is a try_state check for the total issuance trackers, to make sure they are summing to the right values.

However, because the migration runs first, we can never reach a state where the try_state check fails.

Removing the migration run appears to create a fail-state for the try_state check, meaning some difference in the balances pallet TotalIssuance is differing from what we are tracking with the Subtensor pallet TotalIssuance.

My first assumption is the extrinsic fees and/or the balances pallet's account kill, where it burns the remainder of the balance below the existential deposit.

To Reproduce

1. Remove call to run migration for pallet_subtensor::migrations::migrate_init_total_issuance::initialise_total_issuance
2. Run a try-runtime check locally
3. Error: ERROR runtime::frame-support] ❌ "SubtensorModule" try_state checks failed: Other("TotalIssuance accounting discrepancy")

Expected behavior

I would expect the total issuance to not differ between the storage values, as the try_state expects.

Screenshots

No response

Environment

Subtensor 201

Additional context

No response

[orriin]

It does handle transaction fees: https://github.com/opentensor/subtensor/blob/0b2f65c1f8f5e69fc01d2eae37630e50278dc7ac/runtime/src/lib.rs#L394-L409

This rounding issue is tiny (~20 rao) due to floating point arithmetic issues.

[camfairchild]

It does handle transaction fees:

https://github.com/opentensor/subtensor/blob/0b2f65c1f8f5e69fc01d2eae37630e50278dc7ac/runtime/src/lib.rs#L394-L409

This rounding issue is tiny (~20 rao) due to floating point arithmetic issues.

does this hook on account kill sweeps?