Encore une petite friction avec la mise à jour v0.9.42. Le système de référence providers/sufficients/consumers
a été largement modifié. La partie qui pose problème est que request_distance_evaluation
utilise reserve
qui nécessite un provider.
assert_ok!(Distance::request_distance_evaluation(
frame_system::RawOrigin::Signed(AccountKeyring::Eve.to_account_id()).into(),
));
retourne donc l’erreur
---- test_validate_identity_when_claim stdout ----
thread 'test_validate_identity_when_claim' panicked at runtime/gdev/tests/integration_tests.rs:334:13:
Expected Ok(_). Got Err(
DispatchErrorWithPostInfo {
post_info: PostDispatchInfo {
actual_weight: None,
pays_fee: Pays::Yes,
},
error: NoProviders,
},
)
À investiguer…
[edit] plus de détails :
request_distance_evaluation
do_request_distance_evaluation
reserve
try_mutate_account_handling_dust
try_mutate_account
did_consume = false
puisque initialementaccount.reserved
est à zérodoes_consume = true
puisque l’on cherche à augmenter “reserved”inc_consumers
puisqu’on passe d’un compte sans consumer à un compte avecproviders = 0
puisque personne ne provide pour ce compteNoProviders
Après réflexion, c’est compréhensible : l’identité créée n’est que sufficient
, elle ne provide
pas l’existence du compte. Il doit manquer un inc_providers
au moment de la création du compte (garanti par le dépôt existentiel).
[edit] c’est bon, en fait en réglant le bug du total_issuance
(Total issuance vs monetary mass) j’en ai révélé un autre sur l’initialisation des providers
au genesis par la pallet duniter-account
. Il a suffi de s’inspirer de ce qui était fait dans la pallet balances
.