🐛 Fix needflow nodes rendering as black when no type color is set#1702
Merged
Conversation
When a `needs_types` entry omitted the `color` field, the API fell back to `#000000`. That value was then forwarded to PlantUML as a node background color and to Graphviz as `fillcolor` with `style=filled`, producing very dark, unreadable nodes — especially under browser dark mode (issue #1664). The default is now an empty string. Each diagram emitter skips the color suffix / `style=filled` when no color is configured, so the diagram engine's own default node color is used.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1702 +/- ##
==========================================
+ Coverage 86.87% 89.31% +2.43%
==========================================
Files 56 72 +16
Lines 6532 10328 +3796
==========================================
+ Hits 5675 9224 +3549
- Misses 857 1104 +247
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
chrisjsewell
approved these changes
May 18, 2026
Member
chrisjsewell
left a comment
There was a problem hiding this comment.
I have scrutinised the code, but the change makes sense in principle.
Perhaps this is somewhat of a breaking change (changing the default) and this should be made clear
Per review feedback on #1702: the switch from a hard-coded `#000000` fallback to "no color emitted" changes the rendered output for users with `needs_types` entries that omit the `color` key. Call this out explicitly in the changelog and document how to restore the previous appearance.
Member
Author
|
I added a note to the changelog entry to point out the possibly backwards incompatible change. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #1664.
When a
needs_typesentry omitted thecolorfield,generate_needfell back to#000000. That value was then forwarded to PlantUML as the node background colour and to Graphviz asfillcolorwithstyle=filled, producing very dark, unreadable nodes — especially under browser forced dark mode.The default is now an empty string. Each diagram emitter skips the colour suffix /
style=filledwhen no colour is configured, so the diagram engine's own default node colour is used.Why this only surfaced recently
The
#000000fallback has been in the code since 1.0, but it was unreachable until 3.0.0 (Aug 2024). Before PR #1185 (commiteee2eb40), the code used bracket access —ntype["color"] or "#000000"— so aneeds_typesentry missingcolorraisedKeyErrorat build time and the field was de facto required. PR #1185 madecoloran optionalNotRequired[str]and switched tontype.get("color") or "#000000", which silently substitutes the black fallback for users who omit the field.Sphinx / PlantUML / Graphviz versions are not factors — the bug is purely on the Sphinx-Needs side and reproduces with every renderer version. Forced dark mode doesn't cause it; it just removes the surrounding light page that previously made the broken render mildly visible, which is why bug reports started arriving.
Changes
sphinx_needs/api/need.py: defaulttype_colorto""instead of"#000000".sphinx_needs/directives/needflow/_plantuml.py: only emit the#colorsuffix when a colour is set.sphinx_needs/directives/needflow/_graphviz.py(subgraph path): only setstyle=filledwhen there is a fill colour. The plain-node path already had this guard.sphinx_needs/directives/needuml.py: same conditional#coloremission as needflow.sphinx_needs/directives/needgantt.py: skip theis colored in …line when no colour is set.sphinx_needs/config.py: update theNeedType.colordocstring.docs/changelog.rst: bug-fix entry under a new "Unreleased" section.Test plan
tests/test_github_issues.py::test_doc_github_1664covering bothplantumlandgraphvizengines with aneeds_typesentry that has nocolorfield.sphinx_ai_indexextension are unrelated).