Skip to content
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

[4.1.0.rc3] Error to download PDF or Image #30645

Closed
3 tasks
jacob-roldan opened this issue Oct 17, 2024 · 8 comments · Fixed by #30755
Closed
3 tasks

[4.1.0.rc3] Error to download PDF or Image #30645

jacob-roldan opened this issue Oct 17, 2024 · 8 comments · Fixed by #30755
Assignees
Labels
dashboard:export Related to exporting dashboards

Comments

@jacob-roldan
Copy link

Bug description

Go to one Dashboard
3 dots top right / Download / Export to PDF or Download as Image

One error message is showed. See screenshot

I've tested in environment http://35.87.42.94:8080/

Screenshots/recordings

image

Superset version

master / latest-dev

Python version

3.9

Node version

16

Browser

Chrome

Additional context

No response

Checklist

  • I have searched Superset docs and Slack and didn't find a solution to my problem.
  • I have searched the GitHub issue tracker and didn't find a similar bug report.
  • I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.
Copy link

dosubot bot commented Oct 17, 2024

Hey @jacob-roldan! 👋 I'm here to help you with any bugs, questions, or becoming a contributor. Let's squash those bugs together!

I found a similar open issue that might be related to the problem you're experiencing: Upon download as PDF, charts on a long dashboard render as loading image. This issue suggests that the problem might be due to the virtualization feature, which off-loads charts that are away from the viewport. A workaround is to disable the virtualization feature by updating the Superset configuration:

  1. Open the superset_config_docker.py file.

  2. Update the FEATURE_FLAGS variable as follows:

    FEATURE_FLAGS = {
        "DASHBOARD_VIRTUALIZATION": False,
    }

This change ensures that the dashboard loads all charts at once, preventing loading spinners from appearing in the downloaded PDF or image [1].

To continue talking to Dosu, mention @dosu.

@dosubot dosubot bot added the dashboard:export Related to exporting dashboards label Oct 17, 2024
@jacob-roldan jacob-roldan changed the title [4.0.1.rc3] Error to download PDF or Image [4.1.0.rc3] Error to download PDF or Image Oct 17, 2024
@sadpandajoe sadpandajoe moved this to New Issues in Apache Superset 4.1 Oct 17, 2024
@sadpandajoe
Copy link
Member

@geido i can't remember if i should have spun this up with a feature flag or not.

@sadpandajoe
Copy link
Member

@jacob-roldan I ran this on an instance I have and it looks like I do see that message for a bit (maybe a minute or two) but eventually the dashboard does download. How long did you wait until moving away from the dashboard?

@michael-s-molina
Copy link
Member

@sadpandajoe I can also confirm this problem using our internal test environment.

4.0.2

Screen.Recording.2024-10-17.at.16.25.03.mov

4.1.0rc3

Screen.Recording.2024-10-17.at.16.24.08.mov

@michael-s-molina michael-s-molina moved this from New Issues to Release Blockers in Apache Superset 4.1 Oct 17, 2024
@michael-s-molina
Copy link
Member

Is there any configuration change between 4.0.2 and 4.1.0rc3 that is needed to generate the screenshots?

@sadpandajoe
Copy link
Member

@michael-s-molina @jacob-roldan are there any logs? We've actually been running this code on prod for a bit and haven't gotten this issue. Trying to debug this but can't seem to repro it on our end.

@michael-s-molina
Copy link
Member

michael-s-molina commented Oct 18, 2024

@sadpandajoe @geido @eschutho I was able to pinpoint the problem. The reason for the failure is because the screenshot generation on 4.1.0 RC3 caches the screenshots using the THUMBNAIL_CACHE_CONFIG which is a NullCache by default. A NullCache is a cache that does not cache anything, and that's why the frontend cannot find the screenshots and enters in a loop. The fix for this would be to make the default configuration of THUMBNAIL_CACHE_CONFIG similar to what we do with the Explore form data and save the thumbnails in the database using the SupersetMetastoreCache:

THUMBNAIL_CACHE_CONFIG = {
    "CACHE_TYPE": "SupersetMetastoreCache",
    "CACHE_DEFAULT_TIMEOUT": // set a value
    # Should the timeout be reset when retrieving a cached value?
    "REFRESH_TIMEOUT_ON_RETRIEVAL": True,
    # The following parameter only applies to `MetastoreCache`:
    # How should entries be serialized/deserialized?
    "CODEC": // define the appropriate codec
}

Talking to @villebro about this issue, he raised a good point where previously Celery workers were not a hard requirement to install Superset but more of an optional feature. If the screenshot generation always requires Celery workers from now on, that could constitute a breaking change. Let me know your thoughts.

@geido
Copy link
Member

geido commented Oct 22, 2024

@sadpandajoe @geido @eschutho I was able to pinpoint the problem. The reason for the failure is because the screenshot generation on 4.1.0 RC3 caches the screenshots using the THUMBNAIL_CACHE_CONFIG which is a NullCache by default. A NullCache is a cache that does not cache anything, and that's why the frontend cannot find the screenshots and enters in a loop. The fix for this would be to make the default configuration of THUMBNAIL_CACHE_CONFIG similar to what we do with the Explore form data and save the thumbnails in the database using the SupersetMetastoreCache:

THUMBNAIL_CACHE_CONFIG = {
    "CACHE_TYPE": "SupersetMetastoreCache",
    "CACHE_DEFAULT_TIMEOUT": // set a value
    # Should the timeout be reset when retrieving a cached value?
    "REFRESH_TIMEOUT_ON_RETRIEVAL": True,
    # The following parameter only applies to `MetastoreCache`:
    # How should entries be serialized/deserialized?
    "CODEC": // define the appropriate codec
}

Talking to @villebro about this issue, he raised a good point where previously Celery workers were not a hard requirement to install Superset but more of an optional feature. If the screenshot generation always requires Celery workers from now on, that could constitute a breaking change. Let me know your thoughts.

Thanks @michael-s-molina we are currently discussing what the next steps should be for having Celery optional and the cache.

@github-project-automation github-project-automation bot moved this from Release Blockers to Done in Apache Superset 4.1 Nov 1, 2024
@sadpandajoe sadpandajoe moved this from Done to Cherried in Apache Superset 4.1 Nov 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dashboard:export Related to exporting dashboards
Projects
No open projects
Status: Cherried
Development

Successfully merging a pull request may close this issue.

4 participants