Plotly.js: Plotly.deleteTraces leads to bad trace uid sequence

[etpinard]

Consider

Plotly.newPlot('graph', [{
  y: [1, 2, 1]
}, {
  y: [2, 1, 2]
}, {
  y: [3, 2, 3]
}])
.then(gd => {
  console.log(gd._fullData.map(t => t.uid))
  // => ['0', '1', '2']
  return gd
})
.then(gd => {
  return Plotly.deleteTraces(gd, [0])
})
.then(gd => {
  console.log(gd._fullData.map(t => t.uid))
  // (currently) => ['0', '1']
  // (in 1.38.x) => ['1', '2']
})

In a codepen: https://codepen.io/etpinard/pen/KBmVYB?editors=1010

This is probably due to https://github.com/plotly/plotly.js/pull/2681 and probably leads to bugs (not yet reported) when deleting traces in subplots that track traces using uids e.g. gl3d:

https://github.com/plotly/plotly.js/blob/180b6b9225173e834ff92245b6f3620bfcfd14a8/src/plots/gl3d/scene.js#L452-L471

cc @alexcjohnson

[alexcjohnson]

Ah interesting... good catch, because of how getTraceUids pulls uids out of oldFullData, any operation that can alter existing trace indices - so not just delete but also move and add (if not adding at the end) - will have the same issue. I guess the easiest may be to mirror these operations in fullData? Are there similar bugs due to relinkPrivateKeys after a delete etc?

[etpinard]

I guess the easiest may be to mirror these operations in fullData

This won't be trivial for graphs with one-to-many trace transforms (e.g. groupby), what if instead we mirror these operations on a uid stash?