Struct RelationshipGraph 

pub struct RelationshipGraph<'a> { /* private fields */ }

The in-memory relationship graph: one adjacency build, every derived read.

The struct is built once per read from an in-memory issue set — no filesystem access — and answers relationships_for, blocks, blocked_by, duplicates_of, related_to, dependency_chain, blocked_state, and validate_snapshot from the same indices.

Implementations

impl<'a> RelationshipGraph<'a>

pub fn validation_passes(&self) -> usize

How many validation passes this graph has run. See RelationshipGraph::validation_passes for why this exists.

pub fn new(issues: &[IssueView<'a>], done_column: &str) -> Self

Build the graph from an in-memory issue set.

done_column is the board’s configured completion column, used by the resolution predicate in RelationshipGraph::blocked_state. Pass the configured value (BoardConfiguration::effective_done_column), never a hard-coded "done".

An empty done_column is accepted and means no column marks completion, so nothing is treated as done. Config validation keeps columns non-empty in practice, but a caller that passes "" must not silently get “an empty status counts as completed”.

pub fn done_column(&self) -> &str

The configured completion column used by the resolution predicate.

pub fn issue_count(&self) -> usize

How many issues are in the graph.

pub fn identity_index_size(&self) -> usize

How many records the one alias index owns.

pub fn identity_nodes_scanned(&self) -> usize

How many issue records the single alias-index pass examined.

pub fn edge_count(&self) -> usize

How many stored edges are in the graph.

pub fn issue_numbers(&self) -> &[u32]

The issue numbers, ascending.

pub fn has_issue(&self, number: u32) -> bool

Whether number resolves to an issue in the graph.

pub fn find_relationship(&self, id: &str) -> Option<&Relationship>

The stored relationship with this stable id, if any.

pub fn find_canonical( &self, from: u32, to: u32, kind: RelationKind, ) -> Option<&Relationship>

The stored relationship for this canonical (from, to, kind), if any.

This is the service’s answer to “are these the same relationship?” A write path must use it rather than comparing endpoints itself, because the comparison is domain logic and getting it wrong silently breaks idempotency. tix link 1 2 --type blocked_by and tix link 2 1 --type blocks name one edge; a caller comparing the authored endpoints would see two and append a second row.

from, to and kind are the authored values. Canonicalization happens here, so the caller cannot get the direction convention wrong:

• blocked_by is normalized to the equivalent blocks edge with the endpoints swapped;
• related is order-normalized, so either orientation finds the row.

When redundant rows exist for one canonical triple — a hand-edited file can hold two spellings of one association — the lowest-id row is returned, so the answer is stable across builds.

pub fn all_relationships(&self) -> &[Relationship]

Every stored relationship, in deterministic order.

pub fn relationships_for(&self, number: u32) -> Vec<&Relationship>

Every relationship touching number from either endpoint, in deterministic (kind, target) order.

An unknown issue yields an empty vector rather than an error; callers that need an unknown_issue signal check RelationshipGraph::has_issue.

pub fn relationships_of_kind( &self, number: u32, kind: RelationKind, ) -> Vec<&Relationship>

Relationships authored by number with the given kind.

pub fn blocks(&self, number: u32) -> &[u32]

Issues number blocks, ascending.

pub fn blocked_by(&self, number: u32) -> &[u32]

Issues blocking number, ascending.

This is the raw inbound adjacency. It is not the open-blocker set — use RelationshipGraph::blocked_state for that, which applies the resolution predicate.

pub fn duplicates_of(&self, number: u32) -> Vec<u32>

Issues duplicated by number, ascending.

duplicates is directional (data-model.md section 1), so this is deliberately one-directional: it reports the targets of the edges number declares and ignores edges that merely point at number. On a stored 2 duplicates 1 edge the answer is therefore empty — the claim is “2 duplicates 1”, not “1 duplicates 2”. Reading r.to over every edge touching the subject instead reports the subject itself (P4).

pub fn related_to(&self, number: u32) -> Vec<u32>

Issues associated with number by a related edge, ascending.

related is the one non-directional kind, so both endpoints are equivalent. relationships_for returns edges from both sides, so the other side of each edge is projected explicitly — reading r.to directly reports the subject itself for an edge authored from the far side (P3).

Redundant rows collapse here rather than in the stored edge set: two spellings of one association are one relationship to the user, and discarding a row at build time would silently invalidate an id the user still holds (round 3, finding A).

pub fn open_blockers(&self, number: u32) -> Vec<ChainNode>

The open blockers of number, per the resolution predicate.

An inbound blocks edge counts iff the blocker is a different existing issue and its status is not the configured done_column. A dangling edge is excluded here (validation reports it as missing_target) so invalid data cannot permanently freeze an issue.

pub fn blocked_state(&self, number: u32) -> BlockedState

The derived blocked state for number.

reason is the text the move warning and the detail view both display, so the two surfaces cannot drift.

pub fn dependency_chain(&self, root: u32) -> DependencyChain

The transitive dependency chain of root, walking outbound blocks edges: the issues this one blocks, and what they block in turn.

Direction note: data-model.md §9 specifies the chain is derived “from outbound blocks edges”, so this follows blocks_out and answers “what does this issue hold up?”. The opposite question — “what blocks this issue?” — is what the move guard needs, and is answered by RelationshipGraph::open_blockers over the inbound adjacency.

The traversal is iterative and marks visited nodes, so a hand-edited cyclic file terminates instead of hanging the TUI.

pub fn validate_snapshot(&self) -> RelationshipValidationResult

Sweep every stored edge and every issue, reporting every problem.

A single O(V + E) pass, never an Err: tix lint consumes the returned value. Cycle detection reuses the blocks adjacency built at construction, so it is not a second scan.

pub fn validate_create( &self, from: u32, to: u32, kind: RelationKind, ) -> RelationshipValidationResult

Validate a proposed relationship creation.

Runs every per-edge rule plus the cycle check, so the caller gets one blocking verdict before touching any file (SC-005).

pub fn validate_create_ref( &self, from: IssueRef, to: IssueRef, kind: RelationKind, ) -> RelationshipValidationResult

Canonical-reference form of Self::validate_create.

pub fn validate_edit( &self, id: &str, new_to: Option<u32>, new_kind: Option<RelationKind>, ) -> RelationshipValidationResult

Validate a proposed edit of an existing relationship.

An edit naming its own current target and kind is the identity, not a duplicate — and nothing else is forgiven. The edit must still agree with the graph as it already stands, so validate_edit never returns a cleaner verdict than validate_snapshot for the same stored data.

Trait Implementations

impl Clone for RelationshipGraph<'_>

fn clone(&self) -> Self

A copy starts its own count. Cloning a graph is building a new one, so inheriting the source’s pass count would make the instrument lie.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl<'a> Debug for RelationshipGraph<'a>

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.