Skip to content

fix(universalTransition): skip array seriesKey members missing from the old series - #21788

Open
b091 wants to merge 1 commit into
apache:masterfrom
b091:fix-universal-transition-array-series-key
Open

b091 wants to merge 1 commit into
apache:masterfrom
b091:fix-universal-transition-array-series-key

Conversation

@b091

@b091 b091 commented Oct 12, 2026

Copy link
Copy Markdown

Brief Information

This pull request is in the type of:

  • bug fixing
  • new feature
  • others

What does this PR do?

Stops universalTransition from throwing when a series' array seriesKey contains members that don't exist among the previous update's series.

Fixed issues

N.A. (no existing issue found; happy to open one if preferred)

Details

Before: What was the problem?

In findTransitionSeriesBatches, when a new series has an array seriesKey that does not match an old series' key as a whole, each member is looked up in oldDataMap and dereferenced without a check:

const oldData = oldDataMap.get(key);
if (oldData.data) { // TypeError when `key` was not an old series key

Common trigger: a pie that merges several series (one key per category) and whose categories change between updates. For example, a dashboard filter shrinks the categories from ['A', 'B'] to ['B']:

const pie = groups => ({
    series: [{
        type: 'pie',
        universalTransition: { enabled: true, seriesKey: groups.map(g => 'metric-' + g) },
        data: groups.map((g, i) => ({ name: g, value: i + 1 }))
    }]
});
chart.setOption(pie(['A', 'B']));
chart.setOption(pie(['B']), { replaceMerge: ['series'] });
// TypeError: Cannot read properties of undefined (reading 'data')

The error is also sticky. It is thrown before the series:transition handler saves the current series as the next update's "old series", so every later update with the same keys throws again until the key set happens to match the old one. With lazyUpdate, it surfaces as an uncaught error on the zrender frame.

After: How does it behave after the fixing?

Members with no old series are skipped, like the existing if (oldData.data) check already intends. If none of the members match, no transition batch is created and the regular update animation runs. Members that do match still transition as before.

Added test/ut/spec/series/pie.test.ts. It reproduces the case above, including the repeated update, and asserts the update completes. It fails on master with TypeError: Cannot read properties of undefined (reading 'data') and passes with the fix. npm run test passes (27 suites, 195 tests), and npx tsc --noEmit is clean.

Document Info

One of the following should be checked.

  • This PR doesn't relate to document changes
  • The document should be updated later
  • The document changes have been made in apache/echarts-doc#xxx

Misc

Security Checking

  • This PR uses security-sensitive Web APIs.

ZRender Changes

  • This PR depends on ZRender changes (ecomfe/zrender#xxx).

Related test cases or examples to use the new APIs

N.A.

Merging options

  • Please squash the commits into a single one when merging.

Other information

Found in production on echarts 6.1.0. The same line is unchanged on master.

…he old series

When a series declares an array seriesKey and its members change between updates (e.g. a pie whose categories shrink after filtering), findTransitionSeriesBatches looked up each member in oldDataMap and dereferenced undefined. The throw also skipped saving the old series, so every later update threw again.
@echarts-bot

echarts-bot Bot commented Oct 12, 2026

Copy link
Copy Markdown

Thanks for your contribution!
The community will review it ASAP. In the meanwhile, please checkout the coding standard and Wiki about How to make a pull request.

Please DO NOT commit the files in dist, i18n, and ssr/client/dist folders in a non-release pull request. These folders are for release use only.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant