SceneTimeRange: Support delay now to avoid data drops in charts

[ivanortegaalba]

Dashboards PR: grafana/grafana#79703

This enables support for UNSAFE_nowDelay in Dashboards. It is prefixed as UNSAFE because we don't know how used and useful is this.

This allows us to override the now time by entering a time delay. This option accommodates known delays in data aggregation to avoid null values.

[torkelo]

I wonder how much this option is actually for used. It has worked a bit badly for years , wonder if we should consider depreciating it.

[torkelo]

Suggested change

	this.state.nowDelay
	this.getAncestorTimeRange().state.nowDelay,

[ivanortegaalba]

Why should we use the nowDelay from the parent only if the timezone is gotten from it?

If we do that, the nowDelay will be only inherited from the ancestor if the timezone is not defined and if the ancestor time range changes.

The delay should be always the defined one, although we want to inherit any delay from parents, which implies many more changes, since we need to always get the delay from the ancestor as we do for the timezone, not only in the evaluation of the value when the timezone changes.

Am I missing something @torkelo? 🤔

[torkelo]

I think this looks good (with one minor issue)

it is a feature I am interested in how many actually use, and if we can deprecate it maybe, or find a simpler implementation for. Wonder if we can mark it as internal here in scenes lib?

The problem with how it's imlemented now (and here) s that it causes simple time ranges like Last 15 minutes to read like now-30m to now-1m . I think this now delay should not change how intervals are displayed, just how "now" is evaluated.

An alternative change would be to introduce a global "nowDelay" state that we check in dateMath.parse , so it only changes how we interprete "now", the time range picker and the display of the selected time range does not need to change.

thoughts @dprokop @thanos-karachalios ?

[ivanortegaalba]

I wonder how much this option is actually for used. It has worked a bit badly for years, wonder if we should consider depreciating it.

I opened this PR to track the usage of this setting, so we can track how many dashboards that are actually used contains those settings grafana/grafana#79744

[dprokop]

Wonder if we can mark it as internal here in scenes lib?

I think this is a good idea. Let's gather some insights on the usage (thanks @ivanortegaalba for opening the PR!) and decide based on that if deprecation is a way to go.

@torkelo @ivanortegaalba do we agree on continuing with the _UNSAFE_internalPropertyName naming convention for such things? Ref #396

[ivanortegaalba]

Wonder if we can mark it as internal here in scenes lib?

I think this is a good idea. Let's gather some insights on the usage (thanks @ivanortegaalba for opening the PR!) and decide based on that if deprecation is a way to go.

@torkelo @ivanortegaalba do we agree on continuing with the _UNSAFE_internalPropertyName naming convention for such things? Ref #396

I'm ok with that. I like the way to mark it as "do not use it". I'll apply the changes

[ivanortegaalba]

@dprokop I renamed the state property from delayNow to UNSAFE_delayNow. Once you give me the ✅, I'll merge

[ivanortegaalba]

The problem with how it's imlemented now (and here) s that it causes simple time ranges like Last 15 minutes to read like now-30m to now-1m . I think this now delay should not change how intervals are displayed, just how "now" is evaluated.

@torkelo I also fixed the display issue with the time range

[torkelo]

@ivanortegaalba great, I think this is ready for merge then!

[grafanabot]

🚀 PR was released in v1.28.6 🚀