Ignoring coloraxis: ${colorAx} setting as it is linked to in

Error message

Ignoring coloraxis: ${colorAx} setting as it is linked to incompatible colorscales.

What it means

When multiple traces share a layout coloraxis, plotly.js computes a shared colorbar; if the traces linked to that coloraxis carry incompatible colorscales (e.g. one sequential, one reversed or different ranges), the library warns and ignores the coloraxis setting rather than producing a misleading merged colorbar.

Source

Thrown at src/components/colorscale/defaults.js:63

    if(inTrace) {
        var colorAxes = layout._colorAxes || {};
        var colorAx = coerce(prefix + 'coloraxis');

        if(colorAx) {
            var colorbarVisuals = (
                traceIs(parentContOut, 'contour') &&
                Lib.nestedProperty(parentContOut, 'contours.coloring').get()
            ) || 'heatmap';

            var stash = colorAxes[colorAx];

            if(stash) {
                stash[2].push(thisFn);

                if(stash[0] !== colorbarVisuals) {
                    stash[0] = false;
                    Lib.warn([
                        'Ignoring coloraxis:', colorAx, 'setting',
                        'as it is linked to incompatible colorscales.'
                    ].join(' '));
                }
            } else {
                // stash:
                // - colorbar visual 'type'
                // - colorbar options to help in Colorbar.draw
                // - list of colorScaleDefaults wrapper functions
                colorAxes[colorAx] = [colorbarVisuals, parentContOut, [thisFn]];
            }
            return;
        }
    }

    var minIn = containerIn[cLetter + 'min'];
    var maxIn = containerIn[cLetter + 'max'];
    var validMinMax = isNumeric(minIn) && isNumeric(maxIn) && (minIn < maxIn);

View on GitHub (pinned to 1d090e0b5f)

Solutions

Align the colorscale (and cmin/cmax) of every trace that references the shared coloraxis.
Split incompatible traces onto separate coloraxes (coloraxis, coloraxis2) so each has a coherent scale.
Remove per-trace colorscale overrides and rely on the layout.coloraxis definition.
Reversing: use a single direction consistently; avoid mixing reversed scales across linked traces.
Check which traces bind to the axis via their *_coloraxis attributes and audit them together.

Example fix

// before
{layout: {coloraxis: {colorscale: 'Viridis'}}, traces with scales: ['Hot', 'Viridis']}
// after
{layout: {coloraxis: {colorscale: 'Viridis'}, coloraxis2: {colorscale: 'Hot'}},
 traces: [{marker: {coloraxis: 'coloraxis'}}, {marker: {coloraxis: 'coloraxis2'}}]}

Defensive patterns

Strategy: validation

Validate before calling

function coloraxesCompatible(traces, axId) {
  const linked = traces.filter(t => (t.marker && t.marker.coloraxis) === axId || (t.line && t.line.coloraxis) === axId);
  const scales = new Set(linked.map(t => JSON.stringify(t.marker && t.marker.colorscale)));
  return scales.size <= 1;
}

Prevention

Give every trace linked to one coloraxis the same colorscale and cmin/cmax.
Use distinct coloraxis ids (coloraxis, coloraxis2) for traces needing different scales.
Let layout.coloraxis own the scale; avoid per-trace overrides on linked traces.
Audit templates for coloraxis bindings when figures change shape.

When it happens

Trigger: Setting layout.coloraxis (or coloraxis2, ...) where traces bound to it have conflicting cmin/cmax, reversed scales, or different colorscale arrays; e.g. two scatter traces with marker.coloraxis='coloraxis' but one with colorscale 'Viridis' and another 'Hot' plus distinct ranges.

Common situations: Programmatically merging traces with independently chosen color scales; templates that set a shared coloraxis while data-driven traces override colorscale; using one coloraxis for both a continuous and a diverging-scale trace.

Related errors

Node <nodeIndex> is already part of a group.

AI-assisted analysis of plotly/plotly.js@1d090e0b5f (2026-09-02). Data as JSON: /api/errors/7d6dd74674c061fd. Report an issue: GitHub.