lilab-bcb/cirrocumulus

Failure to load data when a manual color is set for a category whose index is over 40

Closed this issue · 2 comments

Describe the bug
Attempting to manual set a color for a particular category with an index greater than 40 leads to a failure to load the data (with the error "Unable to retrieve the data"). This can happen whether the manual colors are specified in a database or in a JSON file.

To Reproduce
I don't have a specific set of steps to reproduce, but I can describe the issue.

We have a data set that has over 2000 categories (transcriptomic types). At some point, someone tried to set a manual color for one of these types (type number 1976, say). This caused that data to no longer be accessible due to a bug in the way the manual colors are assigned.

What seems to be happening is that when no color map is specified, a default set of 40 colors is created to be cycled through. This happens here:
https://github.com/klarman-cell-observatory/cirrocumulus/blob/58c3f999a8052d28bf821befcd33a81c06ded27e/src/actions/index.js#L2077

At this point, colors is a 40-element array of colors. If this is unaltered, it gets passed to scaleOrdinal as the range, and later on scaleOrdinal will just cycle through those elements if there are more elements in the domain (i.e. the 2000+ categories) than there are colors, which is what you'd want to happen. This is done here:
https://github.com/klarman-cell-observatory/cirrocumulus/blob/58c3f999a8052d28bf821befcd33a81c06ded27e/src/actions/index.js#L2110

However, if a color is manually specified for a type, the index of the type is identified, and the colors array is accessed at that index and set to the specified color. This occurs here:
https://github.com/klarman-cell-observatory/cirrocumulus/blob/58c3f999a8052d28bf821befcd33a81c06ded27e/src/actions/index.js#L2104

When that happens in our case, the colors array suddenly becomes a 1976-length array, but all the values between 40 and 1976 are empty. When these empty color values are accessed later, it throws an error and the data for this feature cannot be loaded.

I believe a solution could be to manually create a full-length color array by cycling through the colors before reassigning the manual colors, but there might be better ways of solving the problem as well.

We are currently working around the issue by modifying the database to remove the manual color assignments, but as soon as a user tries to change a color, the issue could recur, so it's not ideal.

Thanks for reporting the issue. This is fixed in version 1.1.30.

I installed the update, but I'm still running into the issue. I made a pull request #126 that I believe fixes the problem - the color array needs to be filled out before the manual colors are assigned, rather than afterwards as currently implemented.