fix(schema): keep the cached derived-value filter for own-id recomputes#9956
Merged
Conversation
The cross-node getter for display labels and human-friendly ids took the cached template for the target kind and overwrote its filter_key in place before returning it. The self getter hands back that same cached instance, so one cross-node recompute flipped the cached filter from `ids` to the relationship filter for good. A later own-id recompute then queried with the relationship filter, matched no node, and left the stored value stale. Return a copy with the overridden filter instead of mutating the cache.
github-actions
Bot
added
the
group/backend
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
No issues found across 4 files
Confidence score: 5/5
- Automated review surfaced no issues in the provided summaries.
- No files require special attention.
Shadow auto-approve: would auto-approve. Focused bug fix preventing shared cached instances from being mutated by cross-node getters. Bounded change with targeted tests confirming the cached filter is preserved for own-id recomputes.
Re-trigger cubic
gmazoyer
commented
Jul 17, 2026
| import hashlib | ||
| from copy import deepcopy | ||
| from dataclasses import dataclass, field | ||
| from dataclasses import dataclass, field, replace |
Contributor
Author
There was a problem hiding this comment.
TIL about replace()
ajtmccarty
approved these changes
Jul 17, 2026
ajtmccarty
left a comment
ajtmccarty
left a comment
Contributor
There was a problem hiding this comment.
looks like a tough one to find. maybe worth sending to stable first?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
A node's display label and human-friendly id can include a value taken from a related node (read across a relationship). When Infrahub had to rebuild that value for the node itself, it sometimes did not update and kept showing the old value.
How it was found
This turned up while working on #9845 (refresh a reader when its read peer is deleted). After deleting a peer and merging, the reader's computed attribute refreshed, but its display label kept naming the deleted peer. The real cause was a separate, older bug in how display labels and HFIDs are rebuilt, so it gets its own fix here.
The bug
Each kind keeps one cached template for its display label and one for its HFID. Two paths share that cached template: one rebuilds the node by its own id, the other rebuilds it because a related node changed. The related-node path changed a lookup setting on the shared template and never reset it. So once a related-node rebuild had run, the own-id path used the wrong lookup, matched no node, and left the stored value stale.
The fix
The related-node path now works on a copy instead of editing the shared cached template, so the own-id path keeps its correct lookup.
Why this is separate from #9845 and does not replace it
They fix different bugs in different places:
So this PR does not supersede #9845. #9845 stays the main fix; this one clears the remaining display label gap. The delete-peer display label refresh only works once both are in.
Tests
dnode via betabecomesdnode via None) instead of staying stale.