pallet-storage-provider: transfer_agreement_ownership - #405
Conversation
|
/cmd bench --pallet pallet_storage_provider pallet_s3_registry pallet_drive_registry |
|
Command "bench --pallet pallet_storage_provider pallet_s3_registry pallet_drive_registry" has started 🚀 See logs here |
|
Command "bench --pallet pallet_storage_provider pallet_s3_registry pallet_drive_registry" has finished ✅ See logs here DetailsSubweight results:
Command output:args: Namespace(command='bench', continue_on_fail=False, quiet=False, clean=False, runtime=['web3-storage-paseo', 'storage-parachain-runtime'], pallet=['pallet_storage_provider', 'pallet_s3_registry', 'pallet_drive_registry'], steps=50, repeat=20, profile='production') |
The design has specified this call since the start and the event for it was declared from day one, but nothing was ever built; the gap analysis even counted the event as the feature. Owner only: hands the agreement to `new_owner`, who can then top up, extend, settle, or transfer it again. The escrow moves with the owner. The prepaid fee and, for a replica, the unspent sync balance are held on the owner's account and every settlement path draws on that hold, so `move_escrow` transfers the held amount on hold to the new owner in one step. The try-state invariant that holds match per-owner bookkeeping keeps passing. Transferring to oneself is rejected rather than treated as a no-op, so a transfer event always means a change of hands. The replica-provider test helper moves from the holds tests to the shared test module so the transfer tests can use it.
The weight entries in the pallet and both runtimes are hand-written estimates so the runtimes build; `/cmd bench` on the PR replaces them with measured values.
Rust and TypeScript wrappers mirror the other agreement calls. The extensions e2e suite gains a step that transfers Bob's agreement to Charlie, then checks that top-up follows the owner: Bob is refused with NotAgreementOwner and Charlie succeeds.
…fund cleanup_bucket_internal refunds each agreement to its own owner and uses the caller only for the admin check. Once an agreement can change hands, the drive owner named in the event and the account that got the money can differ, so the `refunded` field, documented as returned to the owner, became misleading. It is now `escrow_released` and says where the funds go. No consumer read the old field; the drive UI and SDK only read `drive_id` and `owner`.
…t_storage_provider pallet_s3_registry pallet_drive_registry'
73e607d to
76a6a59
Compare
1 participant
The implementation design has specified
transfer_agreement_ownershipsince the start, the event for it was declared from day one, and the gap analysis in #1 counted the event as the feature. Nothing was ever built; #376 tracks it as DRIFT-015 with the proposal "implement". This does that.Owner only. It hands the agreement to
new_owner, who can then top up, extend, settle, or transfer it again. The escrow moves with the owner: the prepaid fee and, for a replica, the unspent sync balance are held on the owner's account and every settlement path draws on that hold, so the newmove_escrowhelper transfers the held amount on hold to the new owner in one step. The try-state invariant that holds match per-owner bookkeeping keeps passing. Transferring to oneself is rejected rather than treated as a no-op, so a transfer event always means a change of hands.Rust and TypeScript SDK wrappers mirror the other agreement calls, and the extensions e2e suite gains a step that transfers Bob's agreement to Charlie and checks that top-up follows the owner. Bindings are regenerated.
Weights are hand-written estimates in the pallet and both runtimes so the runtimes build. Run
/cmd bench --pallet pallet_storage_provideron this PR to replace them with measured values.Layer 1 after a transfer. The escrow follows the agreement owner by construction:
cleanup_bucket_internalrefunds each agreement to its own owner and uses the caller only for the admin check, sodelete_drivekeeps working for the drive owner and the unspent escrow goes to whoever owns the agreement now. The one loose end was theDriveDeletedevent, which paired the drive owner with arefundedamount that may have gone to someone else; the field is nowescrow_released, documented as going to the agreements' owners. S3 is unaffected:delete_s3_bucketnever touches Layer 0, so it reads neither owner. That S3 leaves the agreement running on delete while drives settle it is a separate inconsistency worth its own issue.