fix: re-resolve graph data-mapping on dataset switch

[vadimpiven]

Problem

Selecting a dataset, running, then switching to a different dataset and running again left the chart's data-mapping pointing at the previous dataset's columns — shown as "Inconsistent value" with no graph. Fresh pages (never opened under the first dataset) rendered correctly, and the weighted/unweighted toggle kept working, which narrowed it down to stale persisted axis selections.

Root cause

The block was pinned to @milaboratories/graph-maker 1.1.222, which gates its default re-resolution behind a data-state-key change and, in that pass, never overwrites a non-readonly axis that already holds a selection. So a dataset switch never cleared the previous dataset's columns. graph-maker 1.4.x removed that gating and re-resolves defaults automatically when the pframe changes — which is why other blocks on this SDK line (e.g. embedding-clustering: SDK 1.79.17 + graph-maker 1.4.6) don't hit this.

Change

Bump the graph-maker catalog pin 1.1.222 → 1.4.6. No block source changes. Builds clean; 1.4.6 is already proven compatible with this SDK line by sibling blocks.

Greptile Summary

Bumps @milaboratories/graph-maker from 1.1.222 to 1.4.6 in the pnpm workspace catalog to fix stale chart axis mappings after a dataset switch. No block source code changes are required — the fix is entirely within the new library version.

• Root cause resolved: graph-maker 1.1.x gated axis re-resolution on a data-state-key change; switching datasets never triggered that key, leaving previous columns in the chart as "Inconsistent value". Version 1.4.6 re-resolves defaults unconditionally when the pframe changes.
• Transitive upgrades in the lockfile: miplots4 1.0.172 → 1.2.2, pf-plots 1.1.61 → 1.4.4, helpers 1.13.0 → 1.14.2 (graph-maker internal), zod 3.24.2 removed.
• Secondary lockfile reshuffles: rolldown-plugin-dts peer key normalized to typescript@5.9.3 across all snapshots; @vitest/coverage-istanbul@4.1.9 now resolves against vitest@4.0.16 inside the vitest@4.1.9 snapshot (cross-version peer mismatch worth verifying in CI).

Touched Terms

Term	Definition	Change in this PR
catalog:	pnpm workspace catalog — centralises exact dependency versions for all packages in the monorepo	@milaboratories/graph-maker pin changed 1.1.222 → 1.4.6
@milaboratories/graph-maker	The chart/graph visualisation library used by the VJ-usage block UI for axis mapping and rendering	Bumped to 1.4.6, which unconditionally re-resolves axis defaults when the pframe changes
data-state-key	Internal gate in graph-maker ≤ 1.1.x that triggered axis-default re-resolution only when this key changed	Removed in 1.4.x; re-resolution now happens on every pframe change
pframe (PlatformaFrame)	The data-frame/container object passed to graph-maker containing the dataset's columns	1.4.6 watches this for changes and re-resolves axis mappings automatically
@milaboratories/miplots4	Transitive plotting library used internally by graph-maker	1.0.172 → 1.2.2 as part of the graph-maker upgrade
@milaboratories/pf-plots	Transitive PlatformaFrame-aware plots library used internally by graph-maker	1.1.61 → 1.4.4; peer dep constraints tightened to exact 1.73.3 for @platforma-sdk/model

Confidence Score: 4/5

Safe to merge — the change is a well-scoped catalog pin with no source-code edits, and the target version is already proven in sibling blocks.

The graph-maker bump itself is straightforward and the changeset is accurately documented. The only thing worth a second look is the @vitest/coverage-istanbul peer wiring in the regenerated lockfile, where vitest@4.1.9's optional coverage dep now resolves against a vitest@4.0.16 snapshot — a cross-version pairing generated by pnpm. If coverage is exercised in CI with vitest@4.1.9, it would be worth confirming that coverage output is unaffected.

pnpm-lock.yaml — the vitest/coverage-istanbul snapshot wiring is worth a quick CI coverage check.

Important Files Changed

Filename	Overview
pnpm-workspace.yaml	Single-line catalog pin change: @milaboratories/graph-maker 1.1.222 → 1.4.6. Clean and consistent with the comment convention (exact versions, no ^ or ~).
pnpm-lock.yaml	Lockfile updated for graph-maker 1.4.6 and its transitive deps (miplots4 1.0.172→1.2.2, pf-plots 1.1.61→1.4.4, helpers 1.13.0→1.14.2, zod 3.24.2 removed). Also includes secondary reshuffles: rolldown-plugin-dts peer key normalized to typescript@5.9.3, and @vitest/coverage-istanbul@4.1.9 now resolves against vitest@4.0.16 peer inside the vitest@4.1.9 snapshot (cross-version mismatch).
.changeset/bump-graph-maker.md	New changeset file tagging both vj-usage packages as patch releases; description is accurate and complete.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[User selects Dataset A & runs block] --> B[graph-maker initializes axis mappings\nto Dataset A columns]
    B --> C[User switches to Dataset B & runs again]
    C --> D{graph-maker version?}

    D -->|1.1.222 - old| E{Did data-state-key change?}
    E -->|No - dataset switch\ndoes not change key| F[Axis mappings kept from Dataset A]
    F --> G["Chart shows 'Inconsistent value'\nNo graph rendered"]

    D -->|1.4.6 - new| H[pframe changed detected\nunconditional re-resolution]
    H --> I[Axis defaults resolved\nto Dataset B columns]
    I --> J[Graph renders correctly]

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A[User selects Dataset A & runs block] --> B[graph-maker initializes axis mappings\nto Dataset A columns]
    B --> C[User switches to Dataset B & runs again]
    C --> D{graph-maker version?}

    D -->|1.1.222 - old| E{Did data-state-key change?}
    E -->|No - dataset switch\ndoes not change key| F[Axis mappings kept from Dataset A]
    F --> G["Chart shows 'Inconsistent value'\nNo graph rendered"]

    D -->|1.4.6 - new| H[pframe changed detected\nunconditional re-resolution]
    H --> I[Axis defaults resolved\nto Dataset B columns]
    I --> J[Graph renders correctly]

Loading

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
pnpm-lock.yaml:8499-8502
**`@vitest/coverage-istanbul` peer version mismatch in lockfile**

The `vitest@4.1.9` snapshot now references `@vitest/coverage-istanbul@4.1.9(vitest@4.0.16(...))` — the coverage plugin snapshot that was built against `vitest@4.0.16` — rather than the same-version snapshot `(vitest@4.1.9)`. Both exist in the lockfile, but `vitest@4.1.9` is being wired to the wrong one. If coverage is collected via `vitest@4.1.9` in CI, the plugin may silently mismatch on internal APIs that diverged between 4.0 and 4.1. Worth verifying that `pnpm run test --coverage` still produces expected output after this lockfile regeneration.

_{Reviews (1): Last reviewed commit: "fix: re-resolve graph data-mapping on da..." | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

Context used:

• Context used - Terms is a types in codebase. Provide the list of ... (source)

[gemini-code-assist]

Code Review

This pull request bumps the @milaboratories/graph-maker dependency from version 1.1.222 to 1.4.6 to resolve an issue with stale graph data-mapping when switching datasets. The reviewer suggests including the @platforma-open/milaboratories.vj-usage.model package in the changeset file as well, since it also depends on @milaboratories/graph-maker and needs its version bumped.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.