Some dashboard charts intermittently fall back to color_scheme instead of label_colors on initial render

[lliudspace]

Bug description

When using label_colors in dashboard JSON metadata, some charts intermittently do not apply the defined colors in "label_colors" and instead fall back to the chart's default color_scheme on initial render.

This issue does not affect all charts consistently:

• Most of the charts correctly apply label_colors
• Some charts (often the first one) fall back to the default color scheme
• The behavior is highly intermittent and not reproducible on every page load

---

Observed behavior

• Only some charts are affected, while others display correct colors
• After user interaction (e.g. clicking legend or refreshing the page), the colors become correct

---

Expected behavior

All charts should consistently apply the label_colors defined in dashboard metadata on initial render.

---

Dashboard label_colors configuration

The dashboard uses the following label_colors configuration:

{
  "label_colors": {
    "60_Crashed": "#8b0000",
    "50_Error": "#ff0000",
    "40_Failed": "#ff8c00",
    "30_Undefined": "#ffd700",
    "20_Passed": "#008000",
    "10_Executed": "#0000ff",
    "01_Invalid": "#ff00ff",
    "00_NoResult": "#808080"
  }
}

Dashboard-level color_scheme is empty, the charts use "supersetColors" as color_scheme.

---

Screenshots/recordings

The following screenshot shows the case when the issue occurs

After refreshing or clicking legend, the colors become correct

---

Superset version

6.0.0

---

Python version

I don't know

Node version

I don't know

Browser

Chrome

Additional context

I have reviewed similar issues related to color assignment and dashboard behavior (e.g. #36406), but I could not find a case fully matching this behavior (intermittent fallback to color_scheme with label_colors defined).

Based on the observed behavior, it seems likely that this is related to rendering order or timing in the frontend. However, this is only a hypothesis.

I would appreciate confirmation from maintainers whether this is an expected limitation, a known issue, or a bug in the current rendering pipeline. Thanks.
``

Checklist

• I have searched Superset docs and Slack and didn't find a solution to my problem.
• I have searched the GitHub issue tracker and didn't find a similar bug report.
• I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

[dosubot]

Hi @lliudspace! I'm Dosu and I'm helping the Apache Superset team.

This is a confirmed bug area that's been reported by multiple users and acknowledged by maintainers as unintended behavior [1]. The root cause is a race condition in the color initialization pipeline — charts that render before applyDashboardLabelsColorOnLoad() finishes applying the dashboard metadata's label_colors to the CategoricalColorNamespace will fall back to the chart's color_scheme palette instead [2].

The dashboard color system has multiple timing-sensitive initialization phases [3]:

1. Dashboard load sets the LabelsColorMapSource.Dashboard mode
2. applyDashboardLabelsColorOnLoad() pushes your label_colors into forced colors
3. Charts render and request colors — if step 2 hasn't completed, they get palette colors instead
4. A final sync (ensureSyncedSharedLabelsColors()) runs after all charts finish, which is why interaction/refresh fixes things

Recent fixes in this area:

• PR #39297 (merged May 2026) addresses a related collision race condition when dashboard-locked colors conflict with palette-assigned colors during rendering. It introduces a AvoidColorsCollision feature flag that detects and reassigns conflicting colors.

Workarounds:

1. Clear accumulated color metadata via the dashboard colors API, then re-save your dashboard with only your intended label_colors:

curl -X PUT "http://your-superset-instance/api/v1/dashboard/{dashboard_id}/colors" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer {your_token}" \
  -d '{
    "label_colors": {"60_Crashed":"#8b0000","50_Error":"#ff0000","40_Failed":"#ff8c00","30_Undefined":"#ffd700","20_Passed":"#008000","10_Executed":"#0000ff","01_Invalid":"#ff00ff","00_NoResult":"#808080"},
    "shared_label_colors": [],
    "map_label_colors": {},
    "color_scheme": "",
    "color_scheme_domain": []
  }'

2. Check for stale shared_label_colors or map_label_colors in your dashboard's JSON metadata — these can accumulate over time and interfere with your explicit label_colors definitions.

To confirm: your hypothesis about rendering order/timing is correct. This isn't an expected limitation but rather a known gap in the initialization sequencing. A maintainer noted this area is "constantly being looked at" and will likely see a larger reinvention at some point [1].

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[lliudspace]

Thanks for the reply @dosu. But the PR you mentioned is not the same as my issue. Can you check again?

[dosubot]

You're right, apologies for the confusion — PR #39297 addresses color collisions (two series getting the same color), not the issue you're describing where label_colors are completely ignored on initial render.

After a deeper look, your issue is a distinct race condition in the dashboard initialization pipeline. Here's what's happening:

The race condition:

The dashboard's color initialization fires asynchronously via applyDashboardLabelsColorOnLoad() [1], which populates forcedItems in CategoricalColorNamespace through a multi-phase applyColors() process [2]. Meanwhile, charts begin rendering in parallel — they don't wait for forced colors to be set. If a chart queries getColor() before the async initialization completes, it falls through the priority hierarchy past forced colors (which are empty) and lands on the default color scheme [3].

Why it's intermittent:

• The dashboard component mounts and triggers both color initialization and chart data fetching concurrently [4]
• Some charts fetch/render faster than others — those that finish before applyColors() populates forcedItems get default colors
• Additionally, there are hardcoded 500ms debounce delays in the sync functions [5] that create timing assumptions

Why interaction fixes it:

After any user interaction, updateDashboardLabelsColor() re-synchronizes colors, and by that point forcedItems is fully populated, so charts get the correct label_colors [6].

Current state: I couldn't find an existing open issue or PR that specifically addresses this initial-render timing bug. The mitigation attempts in the code (a dashboardLabelsColorInitiated state flag and post-render sync) don't fully prevent the first-render mismatch when chart rendering outpaces async color initialization [7].

This appears to be an unaddressed gap in the current rendering pipeline. A potential fix would involve blocking chart rendering until applyDashboardLabelsColorOnLoad() completes, or making the color application synchronous before charts begin their render cycle. This could be worth flagging for maintainer attention as a new bug distinct from the collision issues addressed in recent PRs.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[lliudspace]

Hi @sadpandajoe , based on the reply of dosu, this seems to be a race condition in the dashboard color initialization.

Since you've mentioned color consistency has been challenging in the past, could you confirm whether this behavior is a limitation or a known issue? Thanks!

[krmmkr]

I can confirm, i have faced this issue, but its occasional. Not always happens

[lliudspace]

I can confirm, i have faced this issue, but its occasional. Not always happens

Thanks @krmmkr, for me it was also occasional. So in that case, it does indeed appear that this issue is a limitation. I would still like to hear the maintainer's take on this. Is it possible that this could be somehow fixed in the future?