rollingWindow breaking dateRange in query

[yatesdev]

Describe the bug When using rollingWindow, queries using the same cube but without using that measure, break saying that the dateRange is not defined.

Attempting to use rollingWindow to create a rolling average. When the rollingwindow measure is part of the query, cubejs returns the result, no issue. However, attempting to query anything else in its own query on the cube now fails.

{
  "measures": [
    "OperationsFCDaily.rollingConsumerUnitDailyAvg"
  ],
  "timeDimensions": [
    {
      "dimension": "OperationsFCDaily.reportDate",
      "granularity": "day",
      "dateRange": "yesterday"
    }
  ],
  "filters": []
}

Query of a standard (non rollingWindow measure)

{
  "measures": [
    "OperationsFCDaily.fcFulfillableUnits"
  ],
  "timeDimensions": [
    {
      "dimension": "OperationsFCDaily.reportDate",
      "granularity": "day",
      "dateRange": "yesterday"
    }
  ],
  "filters":[]
}

The response is {"type":"UserError","error":"Time series queries without dateRange aren't supported"} However as shown above, dateRange is defined.

To Reproduce Steps to reproduce the behavior:

1. Create a cube with a rollingWindow measure and a normal measure without.
2. Create a calculated measure using the rollingWindow measure.
3. Make a query that uses the rollingWindow measure. It works as expected.
4. Make a query that uses the normal measure only, with a set dateRange. It fails stating Time series queries without dateRange aren't supported

Expected behavior The query shouldn't fail due to a dateRange not existing because the date range is defined in the query.

Version: 0.20.12

Additional context Using AthenaDriver. It should be noted, that removing the rollingWindow definition from the cube, queries on the normal measures begin to work again.

Cube Definition of the problem:

cube("OperationsFCDaily", {
  sql: `SELECT * FROM fc_sellable_unit_day`,
  measures: {
    fcFulfillableUnits: {
      sql: "fc_fulfillable_units",
      type: "sum",
    },
    fcReservedUnits: {
      sql: "fc_reserved_units",
      type: "sum",
    },
    fcUnsellableUnits: {
      sql: "fc_unsellable_units",
      type: "sum",
    },
    fcNetReceivedUnits: {
      sql: "fc_net_received_units",
      type: "sum",
    },
    consumerUnits: {
      sql: "consumer_units",
      type: "sum",
    },
    rollingConsumerUnitDailyAvg: { //queries on this work
      sql: `consumer_units`,
      type: "avg",
      rollingWindow: {
        trailing: `28 day`,
        offset: `end`,
      },
    },
    fulfillableInventoryInWeeks: { //queries on this work
      sql: `1.0 * ${OperationsFCDaily.fcFulfillableUnits} / COALESCE(${OperationsFCDaily.rollingConsumerUnitDailyAvg} * 7, 0)`,
      type: "number",
    },
    reserveInventoryInWeeks: { //queries on this work
      sql: `1.0 * ${OperationsFCDaily.fcReservedUnits} / COALESCE(${OperationsFCDaily.rollingConsumerUnitDailyAvg} * 7, 0)`,
      type: "number",
    },
  },
  dimensions: {
    id: {
      sql: `${CUBE}.tw_sellable_unit_id || cast(${CUBE}.report_date AS VARCHAR)`,
      type: "string",
      primaryKey: true,
    },
    twSellableUnitId: {
      sql: "tw_sellable_unit_id",
      type: "string",
    },
    twCompanyId: {
      sql: "tw_company_id",
      type: "string",
    },
    twPartnerId: {
      sql: "tw_partner_id",
      type: "string",
    },
    partnerSellableUnitId: {
      sql: "partner_sellable_unit_id",
      type: "string",
    },
    reportDate: {
      sql: `cast(${CUBE}.report_date AS timestamp)`,
      type: "time",
    },
  },
})

[vasilev-alex]

Hi @yatesdev! This is unlikely related to the query execution but rather to the Playground's UI failing to update the state. We did a couple of fixes recently. Would it be possible that you update it to the latest version and see if the error has gone?

[yatesdev]

@vasilev-alex Apologies I haven't been able to get back to you sooner. I do know the issue was occurring on my frontend app, not using the Playground. However in the intervening time, the use case we had for this changed and our resulting schema changes no longer ran into this issue. I'll be optimistic and say you can close this. But if I do have some time over the holidays, I'll try and retest

[vasilev-alex]

@yatesdev will be closing the issue then. Please feel free to reopen it should you encounter this problem again.