shelkesays commented on code in PR #40512: URL: https://github.com/apache/superset/pull/40512#discussion_r3457560214
########## superset/config.py: ########## @@ -196,6 +196,16 @@ def _try_json_readsha(filepath: str, length: int) -> str | None: SUPERSET_DASHBOARD_PERIODICAL_REFRESH_LIMIT = 0 SUPERSET_DASHBOARD_PERIODICAL_REFRESH_WARNING_MESSAGE = None +# Manual dashboard refresh can stagger chart data requests across this many +# milliseconds so they do not all hit the backend at the same instant. This +# defaults to 0, which preserves the original behavior where every chart +# request fires at the same time when the user clicks the Refresh dashboard +# button. Set a positive value to opt in to staggering; the frontend then +# uses the larger of this value and the dashboard's stagger_time metadata. +# If this key is removed entirely (treated as null), the frontend falls back +# to a built-in default of 5000 ms. +SUPERSET_DASHBOARD_MANUAL_REFRESH_STAGGER_MS = 0 Review Comment: This is intentional rather than an oversight. Based on the review discussion above, the default is 0 so existing dashboards keep their current behavior. Some deployments run very short refresh intervals, and turning staggering on for everyone could surprise them, so it is opt-in: operators set a positive value when they want it. I also fixed the frontend hook comment that still called 5000 the shipped default, and updated the PR description so the two line up. ########## docs/docs/faq.mdx: ########## @@ -181,6 +181,20 @@ value in milliseconds in the JSON Metadata field: Here, the entire dashboard will refresh at once if periodic refresh is on. The stagger time of 2.5 seconds is ignored. +The manual **Refresh dashboard** button can also stagger its chart requests, controlled by the +`SUPERSET_DASHBOARD_MANUAL_REFRESH_STAGGER_MS` server config in `superset_config.py`. This defaults +to `0`, which preserves the original behavior where every chart request fires at the same time when +the button is clicked. To opt in to staggering, set a positive number of milliseconds; the window +then becomes the larger of this value and the per-dashboard `stagger_time` metadata. If the config +key is removed entirely (treated as null), the frontend falls back to a built-in default of `5000` +milliseconds. Review Comment: Fair point, the old wording was misleading. I reworded the FAQ and the config comment so the 5000 ms fallback is described as the case where the backend does not send a value at all, such as an older backend that predates the key or a value set to None. Since config.py always ships the key, that path is not a normal operator action, so I dropped the 'remove the key' phrasing. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
