Skip to content

Inform user when trying to download where they dont have the full tree locally #1692

Open

Description

@olizilla

Describe the bug
"Download" gets stuck when you dont have the full tree locally and you are unable to fetch it. Even if you are able to fetch it the download may take a while and appear to stall as the user does not know they are know waiting to find the blocks.

We can check to see if the full tree is available locally before starting the download and warn that we will have to go find the full tree and it could take a while if it isn't all available.

This is easy to trigger know due to the "Import from IPFS" action only importing the root block as per #1691

Activity

  1. added
    exp/intermediatePrior experience is likely helpful
    effort/daysEstimated to take multiple days, but less than a week
    help wantedSeeking public contribution on this issue
    kind/enhancementA net-new feature or improvement to an existing feature
    P1High: Likely tackled by core team if no one steps up
    need/analysisNeeds further analysis before proceeding
    and removed
    need/triageNeeds initial labeling and prioritization
    on Nov 23, 2020
  2. jessicaschilling commented on Nov 23, 2020

    @jessicaschilling
    Contributor

    From today's triage discussion: Actually implementing a fix shouldn't be too difficult, but need some further investigation first, to wit:

    • Determine how expensive it is to tell if an item is available locally or not
    • Determine if we (and if so, how expensive is it) can get a percentage of an item that's available locally

    If it's expensive:

    • Check only at time of download, and if the item isn't fully available locally, give a warning modal that we have to find the full tree and that might take a while if it's not all available

    If it's not expensive:

    • Add a UI element in the Files screen table to indicate whether an item is fully local or not (perhaps including percentage local availability)

    As of time of writing, bandwidth doesn't support our swarming on getting this fixed, but let's keep close to the top of our "quick fixes" priority list.

  3. SgtPooki commented on Dec 2, 2022

    @SgtPooki
    Member

    We need to repro after merging #1894

  4. added
    P3Low: Not priority right now
    and removed
    P1High: Likely tackled by core team if no one steps up
    on Dec 2, 2022
  5. moved this from Needs Grooming to Planned / Backlog in IPFS-GUI (PL EngRes)on Dec 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3Low: Not priority right nowarea/screen/filesIssues related to Files screeneffort/daysEstimated to take multiple days, but less than a weekexp/intermediatePrior experience is likely helpfulhelp wantedSeeking public contribution on this issuekind/enhancementA net-new feature or improvement to an existing featureneed/analysisNeeds further analysis before proceeding

    Type

    No type

    Projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions