Skip to content

Conversation

Abdkhan14
Copy link
Contributor

@Abdkhan14 Abdkhan14 commented Oct 8, 2025

  1. Every node needs to consciously be assigned an id. Helps prevent needing overrides on methods like pathToNode that are derived fromid -> Made id an abstract getter.

  2. Nodes with special hierarchy like parentAutogroupNode, should only be concerned about their node.directVisibleChildren, and how it changes when it's expanded state is toggled. Prevents having to override more generic methods like node.visibleChildren that return all embedded visible children under a node -> Renamed node.directChildren to node.directVisibleChildren and it respects the expanded state. Removed node.visibleChildren overrides. Much cleaner implementation.

  3. Removed redundant node.matchByPath overrides. Nodes won't match anyways, unless the correct path prefix is passed to baseNode.matchByPath. The prefix is determined by node.path that uses the node's specific type and id.

  4. Cleaned up typescript errors from tests, since we no longer need to pass tree static methods down to transactionNodes.

@Abdkhan14 Abdkhan14 requested a review from gggritso October 8, 2025 17:56
@Abdkhan14 Abdkhan14 requested a review from a team as a code owner October 8, 2025 17:56
@github-actions github-actions bot added the Scope: Frontend Automatically applied to PRs that change frontend components label Oct 8, 2025
get id(): string {
const firstChild = this.children[0];
return firstChild?.id;
return firstChild?.id ?? uuid4();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: Node ID Unstability Causes Functionality Failures

The id getters in RootNode, ParentAutogroupNode, and SiblingAutogroupNode use uuid4(). This generates a new UUID on every access, making node IDs unstable. This breaks functionality relying on consistent identifiers, such as node identification, path matching, and caching.

Additional Locations (2)

Fix in Cursor Fix in Web

return false;
}
return this.matchById(id);
return this.id === id;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: Navigation Broken by ID Matching Restriction

The matchByPath method now only matches against a node's primary ID, removing the ability to find nodes by associated error or occurrence event IDs. This breaks navigation for nodes previously discoverable through those secondary IDs.

Fix in Cursor Fix in Web

Comment on lines 182 to 187
}
}

get id(): string | undefined {
return this.value && 'event_id' in this.value ? this.value.event_id : undefined;
}

get op(): string | undefined {
return this.value && 'op' in this.value ? this.value.op : undefined;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Potential bug: Call to non-existent static method causes runtime TypeError
  • Description: A call to a non-existent static method TraceTree.DirectVisibleChildren will cause a runtime TypeError. The refactoring introduced an instance property node.directVisibleChildren but failed to update this specific call site. This will cause a crash when the trace waterfall attempts to display the children count for span rows.

  • Suggested fix: Replace the static method call TraceTree.DirectVisibleChildren(node).length with the instance property node.directVisibleChildren.length.
    severity: 3.0, confidence: 5.0

Did we get this right? 👍 / 👎 to inform future reviews.

Copy link
Member

@gggritso gggritso left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense! The only concern I have is the uuid4() issue that Cursor already pointed out

get id(): string | undefined {
return this.head.id ?? this.tail.id;
get id(): string {
return this.head.id ?? this.tail.id ?? uuid4();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👀 maybe better to use uuid4() at construction time, so it's stable?

canShowDetails = false;

get id(): string {
return uuid4();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same uuid4() note as above

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Scope: Frontend Automatically applied to PRs that change frontend components
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants