rollup_join regression between 1.3.26 and 1.6.69 (multi-cube, zero-measure query), current release 1.7.35 also has this issue — related to #10384

Describe the bug

A multi-cube, multi-data-source rollupJoin pre-aggregation that matched correctly on 1.3.26 stops matching after upgrading to 1.6.69, throwing the cross-data-source error even though a rollupJoin covering exactly those cubes/dimensions is defined. The query itself is unchanged between versions — only the Cube.js version changed.

This looks like the same underlying regression reported in #10384 ("rollup_join regression between 1.3 and 1.6"), which was closed with only "Need to double check if it is a real issue. closing for now" and no further investigation. Filing separately with a fuller repro since that issue was closed without resolution — please link/reopen as appropriate.

Also possibly related (different trigger conditions, but same error and same subsystem): #11124 (measure from secondary cube not matched) and #10104 (set/notSet operator not matched in rollup_join), though neither of those is framed as a version regression the way this and #10384 are.

To Reproduce

Our rollupJoin spans 4 cubes across 4 distinct data sources, and the failing query selects zero measures (dimensions + filters only — a "list records" style query), which rules out the secondary-cube-measure trigger from #11124.

Schema (simplified, names/values anonymized):

cube(`PM_Teams`, {
  // dataSource: propertyManagement
  preAggregations: {
    glRentTenancyTeamsRollup: {
      type: `rollupJoin`,
      measures: [],
      dimensions: [
        PM_Teams.teamId, PM_Teams.propertyAddress, PM_Teams.propertyType,
        Tenancies.tenancyId, Tenancies.renterNames, Tenancies.isCurrentEffectiveTenancy, Tenancies.isOngoingManagement,
        GeneralLedger_RentByTenancy.rentAmount, GeneralLedger_RentByTenancy.firstRentCreatedAt, GeneralLedger_RentByTenancy.lastRentCreatedAt,
        PaymentMethod.methodType,
      ],
      rollups: [
        PM_Teams.pMTeamsRollup,
        Tenancies.tenancyRentersRollup,                // dataSource: default
        GeneralLedger_RentByTenancy.rentTenancyRollup,  // dataSource: generalLedger
        PaymentMethod.methodRollup,                     // dataSource: payment
      ],
    },
  },
});

Query (no measures; dimensions + filters only):

{
  "dimensions": [
    "GeneralLedger_RentByTenancy.rentAmount",
    "GeneralLedger_RentByTenancy.firstRentCreatedAt",
    "GeneralLedger_RentByTenancy.lastRentCreatedAt",
    "PM_Teams.propertyAddress",
    "PM_Teams.propertyType",
    "PM_Teams.teamId",
    "PaymentMethod.methodType",
    "Tenancies.renterNames",
    "Tenancies.managementId"
  ],
  "order": [["PM_Teams.propertyAddress", "asc"]],
  "limit": 5000,
  "filters": [
    { "or": [
      { "member": "PaymentMethod.methodType", "operator": "equals", "values": ["bank_account", "credit_card", "..."] },
      { "member": "PaymentMethod.methodType", "operator": "notSet" }
    ]},
    { "member": "Tenancies.isCurrentEffectiveTenancy", "operator": "equals", "values": ["true"] },
    { "member": "Tenancies.isOngoingManagement", "operator": "equals", "values": ["true"] },
    { "member": "PM_Teams.teamId", "operator": "equals", "values": ["<uuid>", "...(60+ values)"] },
    { "member": "PM_Teams.organisationId", "operator": "equals", "values": ["<uuid>"] },
    { "member": "PM_Teams.propertyType", "operator": "equals", "values": ["Residential", "Commercial"] }
  ]
}

We bisected the query down to a minimal reproduction — removing the OR/notSet filter, removing order, and removing the time-typed dimensions (firstRentCreatedAt/lastRentCreatedAt) one at a time. Every reduction still hit the identical error, so it isn't tied to any specific filter operator or dimension type — it's structural to the 4-way cross-data-source join itself.

Expected behavior

Same as on 1.3.26: the query should route through PM_Teams.glRentTenancyTeamsRollup since every requested dimension and filter member is declared in that rollupJoin's dimensions list, and no measures are requested at all.

Actual behavior

To join across data sources use rollupJoin with Cube Store. If rollupJoin is defined, this error indicates it doesn't match the query. Please use Rollup Designer to verify it's definition. Found data sources: generalLedger, propertyManagement, payment, default

Possible root cause

Diffing packages/cubejs-schema-compiler/src/adapter/PreAggregations.ts between v1.3.26 and v1.6.69, the matching function canUsePreAggregationForTransformedQueryFn dropped a trimmedReferences() normalization step that used to run every pre-aggregation's dimension/measure references through CubeSymbols.joinHintFromPath(...).path before comparing them against the query's own member names:

// present in 1.3.26, removed in 1.6.69
// TODO remove this in favor of matching with join path
function trimmedReferences(references) {
  const dimensionsTrimmed = references.dimensions.map(d => CubeSymbols.joinHintFromPath(d).path);
  ...
}

In 1.6.69 this helper and its TODO are gone; the matcher now compares references.dimensions/references.measures in raw form, with join-path-aware resolution only reintroduced in two narrow call sites (the ungrouped branch and expandTimeDimension) rather than universally. For a rollupJoin spanning many cubes/join paths (4, in our case), if any cross-cube reference ends up carrying a join-hint-qualified path internally, the removed trimming step would previously have normalized it back to a plain Cube.member string before comparison — without it, a legitimate match can silently fail on string comparison. This would explain why simpler, same-data-source rollups are unaffected while multi-cube/multi-data-source rollupJoins regress, and it's consistent with both this report and #10384 (2 cubes/2 data sources) failing the same way despite differently-shaped schemas.

We haven't confirmed this against a debugger/live instance yet — flagging as a starting point, not a confirmed diagnosis.

Version

Regressed between 1.3.26 and 1.6.69. Confirmed still present on 1.6.69 (latest LTS at time of writing).