ryer.io

Version Resolution Refactor: Effective Version & Removing Toggle Plumbing

#gitlab

TL;DR

  • Proposing a backend-computed effective/pinned version based on the user’s current namespace to simplify the frontend.
  • This would fix a bug Agent 4071 identified: disabled items on the managed tab have a null project-level item consumer, causing nullified metadata (bad UX, though not a crash).
  • Previously fixed a related pagination bug where group and project item consumers were double-counted against a 20-item max, limiting fetches to 10 items.
  • Effective version would let the backend return one correct value per namespace instead of two, avoiding pagination issues.
  • Also enables removing active/base version key plumbing (line 103) and the set active version key callback (line 108) by instead linking out to the latest version in a new tab.

If we expose an effective or pinned version on the backend, computed based on the user’s current namespace, we can resolve several issues. First, it fixes a bug Agent 4071 identified with disabled items on the managed tab: when an item is disabled, it has a group item consumer but no project-level item consumer (null), which results in nullified metadata and bad UX, though the app doesn’t crash. Earlier, we fixed a related bug where fetching the group-level item consumer counted twice against a pagination max of 20 items, meaning only 10 items could be fetched before pagination broke; we resolved that by removing the group-level query count since we weren’t using it. But there’s still an edge case: disabling an item in the managing project (previously enabled) leaves a group-level consumer but no project-level one, causing nullified data. Returning an effective version computed on the backend would give the correct value for both group and project namespaces, avoiding the pagination problem entirely. This would also let us eliminate storing the base version key in the version field (line 103 of the AI catalog item view component) and the set active version key callback (line 108), which currently lives outside Vue’s reactivity system. Instead of toggling between versions, the update-available alert could simply link out to the latest version in a new tab, removing the need for active/base version keys altogether – we’d only need to know whether an update is available by comparing the latest version to the pinned item. The version resolution logic still needs to handle group configurations properly for this to work.