GraphiteEditor/Graphite · critical

Ellipse node does not exist

Error message

Ellipse node does not exist

What it means

Arc::create_node resolves the Arc generator node via resolve_proto_node_type(graphene_std::vector::generator_nodes::arc::IDENTIFIER) and unwraps with .expect("Ellipse node does not exist") (arc_shape.rs:134). The lookup consults the static DOCUMENT_NODE_TYPES registry (document_node_definitions.rs:130, 1480) and returns None when the arc identifier is not registered. Note the message is a copy-paste artifact — it says "Ellipse node" while the code resolves the Arc node, so the panic text misleads whoever hits it.

Source

Thrown at editor/src/messages/tool/common_functionality/shapes/arc_shape.rs:134

		if self.arc_radius_handle.hovered() || self.arc_radius_handle.is_dragging() {
			return Some(MouseCursorIcon::EWResize);
		}

		None
	}

	fn cleanup(&mut self) {
		self.sweep_angle_gizmo.cleanup();
		self.arc_radius_handle.cleanup();
	}
}
#[derive(Default)]
pub struct Arc;

impl Arc {
	pub fn create_node(arc_type: ArcType) -> NodeTemplate {
		let node_type = resolve_proto_node_type(graphene_std::vector::generator_nodes::arc::IDENTIFIER).expect("Ellipse node does not exist");
		node_type.node_template_input_override([
			None,
			Some(NodeInput::value(TaggedValue::F64(0.5), false)),
			Some(NodeInput::value(TaggedValue::F64(0.), false)),
			Some(NodeInput::value(TaggedValue::F64(270.), false)),
			Some(NodeInput::value(TaggedValue::ArcType(arc_type), false)),
		])
	}

	pub fn update_shape(
		document: &DocumentMessageHandler,
		ipp: &InputPreprocessorMessageHandler,
		viewport: &ViewportMessageHandler,
		layer: LayerNodeIdentifier,
		shape_tool_data: &mut ShapeToolData,
		modifier: ShapeToolModifierKey,
		responses: &mut VecDeque<Message>,
	) {

View on GitHub (pinned to c507b35645)

Solutions

  1. Confirm resolve_proto_node_type(graphene_std::vector::generator_nodes::arc::IDENTIFIER).is_some() against the registration list in document_node_definitions.rs
  2. Fix the identifier mismatch (const vs registration key) and rebuild
  3. Correct the expect message to "Arc node does not exist" so future hits are diagnosable
  4. Make create_node return Option<NodeTemplate> (or use let-else) so a missing definition surfaces as a graceful failure

Example fix

// before
let node_type = resolve_proto_node_type(graphene_std::vector::generator_nodes::arc::IDENTIFIER).expect("Ellipse node does not exist");
// after
let node_type = resolve_proto_node_type(graphene_std::vector::generator_nodes::arc::IDENTIFIER)
	.expect("Arc node definition missing from DOCUMENT_NODE_TYPES");
Defensive patterns

Strategy: validation

Validate before calling

// Fail in CI, not in the user's tool:
#[test]
fn shape_tool_nodes_registered() {
	assert!(resolve_proto_node_type(graphene_std::vector::generator_nodes::arc::IDENTIFIER).is_some(), "Arc node missing from DOCUMENT_NODE_TYPES");
}

Prevention

When it happens

Trigger: Starting an Arc tool drag (create_node is called when the tool begins a shape) while generator_nodes::arc::IDENTIFIER has no DOCUMENT_NODE_TYPES entry — renamed const, node removed from graphene_std, or registration list edited.

Common situations: Renaming/moving the Arc implementation without updating tool references; Graphite upgrades where generator nodes changed namespace; feature-gated builds excluding the arc module; the misleading message sending debugging toward Ellipse instead.

Related errors


AI-assisted analysis of GraphiteEditor/Graphite@c507b35645 (2026-08-16). Data as JSON: /api/errors/f3621be6dfd8dc1e. Report an issue: GitHub.