Context
The supervision tree view (BeamPIDObject >> gtSupervisionView:) currently lives on the PID tab in the inspector's dual-strip mode switcher. Conceptually, supervision IS state — it belongs on the State tab.
Challenge
The State tab shows a different object (the GenServer state struct from :sys.get_state). The supervision tree needs the PID to query (GtBridge.Analysis.supervision_tree(pid)). These are two different objects with different view collection paths.
DynamicSupervisor (Elixir)
Easy to detect — proper struct with elixirClass = 'DynamicSupervisor'. Could attach supervision view to the state object based on class detection.
Regular Erlang supervisor
Returns a 12-element tuple tagged :state. The tag doesn't include the module name (it's just :state, not :Supervisor.state), making generic identification fragile. Any heuristic based on tuple shape would be brittle.
Approaches Considered
- Side-channel via PID — use the PID as
object: for State tab with a custom viewsSelector that combines state views + supervision view. Works but feels like a hack.
- Detect from tuple shape — heuristic on the state tuple's arity/fields. Fragile for Erlang supervisors.
- Only for DynamicSupervisor — detect
elixirClass = 'DynamicSupervisor' and add supervision view to that struct's views. Works for Elixir but not Erlang supervisors.
Decision
Keep supervision view on PID tab for now. Revisit when we have better Erlang module/tuple type inference.
Related
- Erlang module view support (recognizing tuple types as Erlang module state)
<gtInspectorMode> pragma (dynamic tab registration would let supervisors add their own mode)
Context
The supervision tree view (
BeamPIDObject >> gtSupervisionView:) currently lives on the PID tab in the inspector's dual-strip mode switcher. Conceptually, supervision IS state — it belongs on the State tab.Challenge
The State tab shows a different object (the GenServer state struct from
:sys.get_state). The supervision tree needs the PID to query (GtBridge.Analysis.supervision_tree(pid)). These are two different objects with different view collection paths.DynamicSupervisor (Elixir)
Easy to detect — proper struct with
elixirClass = 'DynamicSupervisor'. Could attach supervision view to the state object based on class detection.Regular Erlang supervisor
Returns a 12-element tuple tagged
:state. The tag doesn't include the module name (it's just:state, not:Supervisor.state), making generic identification fragile. Any heuristic based on tuple shape would be brittle.Approaches Considered
object:for State tab with a customviewsSelectorthat combines state views + supervision view. Works but feels like a hack.elixirClass = 'DynamicSupervisor'and add supervision view to that struct's views. Works for Elixir but not Erlang supervisors.Decision
Keep supervision view on PID tab for now. Revisit when we have better Erlang module/tuple type inference.
Related
<gtInspectorMode>pragma (dynamic tab registration would let supervisors add their own mode)