Release notesRelease notes for Grafana 9.0.0-beta2

Release notes for Grafana 9.0.0-beta2

Features and enhancements

Bug fixes

Breaking changes

Drop support for deprecated setting ldap_sync_ttl under [auth.proxy] Only sync_ttl will work from now on Issue #49902

Removes support for deprecated heading and description props. Moving forward, the Card.Heading and Card.Description components should be used. Issue #49885

Removes the deprecated link variant from the Button component. To migrate, replace any usage of variant="link" with fill="text". Issue #49843

Removes the deprecated surface prop from the IconButton component. This prop hasn’t actually done anything for a while, so it should be safe to just remove any instances of its usage. Issue #49715

Removes the deprecated TextDisplayOptions export from @grafana/data in favor of VizTextDisplayOptions from @grafana/schema. To migrate, just replace usage of TextDisplayOptions with VizTextDisplayOptions. Issue #49705

Removed support for the deprecated getColorForTheme(color: string, theme: GrafanaTheme) function in favor of the theme.visualization.getColorByName(color: string) method. The output of this method is identical to the removed function, so migration should just be a matter of rewriting calls of getColorForTheme(myColor, myTheme) to myTheme.visualization.getColorByName(myColor). Issue #49519

In the Prometheus data source, for consistency and performance reasons, we changed how we represent NaN (not a number) values received from Prometheus. In the past versions, we converted these to null in the frontend (for dashboard and explore), and kept as NaN in the alerting path. Starting with this version, we will always keep it as NaN. This change should be mostly invisible for the users. Issue #49475

Plugins using custom Webpack configs could potentially break due to the changes between webpack@4 and webpack@5. Please refer to the official migration guide for assistance.

Webpack 5 does not include polyfills for node.js core modules by default (e.g. buffer, stream, os). This can result in failed builds for plugins. If polyfills are required it is recommended to create a custom webpack config in the root of the plugin repo and add the required fallbacks:

// webpack.config.js

module.exports.getWebpackConfig = (config, options) => ({
  resolve: {
    fallback: {
      os: require.resolve('os-browserify/browser'),
      stream: require.resolve('stream-browserify'),
      timers: require.resolve('timers-browserify'),

Please refer to the webpack build error messages or the official migration guide for assistance with fallbacks. Issue #47826

We have changed the internals of backendSrv.fetch() to throw an error when the response is an incorrect JSON.

// PREVIOUSLY: this was returning with an empty object {} - in case the response is an invalid JSON
return await getBackendSrv().post(`${API_ROOT}/${id}/install`);

// AFTER THIS CHANGE: the following will throw an error - in case the response is an invalid JSON
return await getBackendSrv().post(`${API_ROOT}/${id}/install`);

When is the response handled as JSON?

  • If the response has the "Content-Type: application/json" header, OR
  • If the backendSrv options (BackendSrvRequest) specify the response as JSON: { responseType: 'json' }

How does it work after this change?

  • In case it is recognised as a JSON response and the response is empty, it returns an empty object {}
  • In case it is recognised as a JSON response and it has formatting errors, it throws an error

How to migrate? Make sure to handle possible errors on the callsite where using backendSrv.fetch() (or any other backendSrv methods). Issue #47493

Plugin development fixes & changes