Metrics actions that rely on a time window will dispatch the same action with a stale time window

To fix this we could do something similar to CfAppAutoscalerEventsDataSource (currently avoided due to updated ctor leading to wide scale change, alternatively could make helper function required a static)

src/frontend/packages/core/src/shared/components/list/data-sources-controllers/list-data-source.ts

  private getRefreshFunction(config: IListDataSourceConfig<A, T>) {
    if (config.listConfig && config.listConfig.hideRefresh) {
      return null;
    }
    return config.refresh ? config.refresh : () => {
      if (Array.isArray(this.action)) {
        this.action.forEach(action => this.store.dispatch(action));
      } else {
        // Metrics actions that rely on a time window will dispatch the same action with a stale time window. To fix this we could do
        // something similar to CfAppAutoscalerEventsDataSource (currently avoided due to updated ctor leading to wide scale change,
        // alternatively could make helper function required a static)
        this.store.dispatch(this.metricsAction || this.masterAction);
      }
    };
  }

Start in src/frontend/packages/core/src/shared/components/list/data-sources-controllers/list-data-source.ts, focusing on getRefreshFunction and how metricsAction and masterAction are constructed. Compare the approach with CfAppAutoscalerEventsDataSource and trace the affected metrics refresh path. Done means a refresh dispatches a current time-window action rather than reusing a stale one, without requiring a broad constructor change.