Skip to content

feat: add delete file extrinsic #426

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 46 commits into
base: main
Choose a base branch
from

Conversation

HermanObst
Copy link
Contributor

Implements a new delete_file extrinsic that allows any entity (fishermen, MSPs, BSPs) to execute file deletions on behalf of users using signed intentions and forest proof verification.

HermanObst and others added 30 commits July 16, 2025 18:31
… at the moment request_delete_file is called
Base automatically changed from ho/delete_file_extrinsic to main July 25, 2025 03:12
@HermanObst HermanObst marked this pull request as ready for review July 29, 2025 00:00
@HermanObst HermanObst requested review from snowmead and TDemeco July 30, 2025 19:05
}

#[test]
fn delete_file_works_with_any_caller() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should add a test as well to ensure that the payment stream is updated (i.e. decreased)

use super::*;

#[test]
fn delete_file_fails_with_invalid_signature() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add a failing and successful test to ensure that the FileOperation is Delete in the intention.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could do it, but as Delete is the only option in the Enum I would need to directly change bytes in the encoded message, as i dont want to add a different operation

Comment on lines 2781 to 2815
// Update the payment stream between the user and the BSP. If the new amount provided is zero, delete it instead.
// Note: This logic is handled by decrease_bucket_size (via apply_delta_fixed_rate_payment_stream) in the case of MSPs.
let new_amount_provided = <T::PaymentStreams as PaymentStreamsInterface>::get_dynamic_rate_payment_stream_amount_provided(&bsp_id, &file_owner)
.ok_or(Error::<T>::DynamicRatePaymentStreamNotFound)?
.saturating_sub(size);
if new_amount_provided.is_zero() {
<T::PaymentStreams as PaymentStreamsInterface>::delete_dynamic_rate_payment_stream(
&bsp_id,
&file_owner,
)?;
} else {
<T::PaymentStreams as PaymentStreamsInterface>::update_dynamic_rate_payment_stream(
&bsp_id,
&file_owner,
&new_amount_provided,
)?;
}

// If the root of the BSP is now the default root, stop its cycles.
if new_root == <T::Providers as shp_traits::ReadProvidersInterface>::get_default_root() {
// Check the current used capacity of the BSP. Since its root is the default one, it should
// be zero.
let used_capacity =
<T::Providers as ReadStorageProvidersInterface>::get_used_capacity(&bsp_id);
if !used_capacity.is_zero() {
// Emit event if we have inconsistency. We can later monitor for those.
Self::deposit_event(Event::UsedCapacityShouldBeZero {
actual_used_capacity: used_capacity,
});
}

// Stop the BSP's challenge and randomness cycles.
<T::ProofDealer as shp_traits::ProofsDealerInterface>::stop_challenge_cycle(&bsp_id)?;
<T::CrRandomness as CommitRevealRandomnessInterface>::stop_randomness_cycle(&bsp_id)?;
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we deduplicate this - we have the same logical sequence in do_bsp_confirm_stop_storing

@HermanObst HermanObst requested a review from snowmead July 31, 2025 20:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants