Location: bionetgen/core/tools/gdiff.py:714
Original marker:
# TODO: Need to get in there and rename and recolor each
# node under the one we just copied
When gdiff copies a node into a derived graph (e.g. when a node exists in one model but not the other), the parent node gets a fresh ID via _set_node_id and the rename map is updated, but the loop below only walks the immediate copy's properties — it does not recurse into the children to rename and recolor them. The result is a graphml output where the copied subtree carries duplicated IDs from the original subtree, which can break downstream graph consumers.
What would unblock this: decide whether the children should:
- Get fresh IDs derived from the parent's new ID (current rename-map convention), and
- Get the parent's color or retain their original colors.
If "fresh IDs + parent color," thread _set_node_id and _set_node_color calls into the existing child-walking loop. If colors should be preserved per-child, only IDs need rewriting.
Discovered during: non-Atomizer TODO/FIXME triage sweep, 2026-05-08.
Location:
bionetgen/core/tools/gdiff.py:714Original marker:
When
gdiffcopies a node into a derived graph (e.g. when a node exists in one model but not the other), the parent node gets a fresh ID via_set_node_idand the rename map is updated, but the loop below only walks the immediate copy's properties — it does not recurse into the children to rename and recolor them. The result is a graphml output where the copied subtree carries duplicated IDs from the original subtree, which can break downstream graph consumers.What would unblock this: decide whether the children should:
If "fresh IDs + parent color," thread
_set_node_idand_set_node_colorcalls into the existing child-walking loop. If colors should be preserved per-child, only IDs need rewriting.Discovered during: non-Atomizer TODO/FIXME triage sweep, 2026-05-08.