Skip to content

MILAB-6382: bump workflow-tengo to 5.24.0 for .gpuMemory() - #2

Merged
blackcat merged 2 commits into
mainfrom
MILAB-6382_sdk-bump-gpumemory
Jun 5, 2026
Merged

MILAB-6382: bump workflow-tengo to 5.24.0 for .gpuMemory()#2
blackcat merged 2 commits into
mainfrom
MILAB-6382_sdk-bump-gpumemory

Conversation

@blackcat

@blackcat blackcat commented Jun 4, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Bumps @platforma-sdk/workflow-tengo from 5.13.15.24.0 so .gpuMemory() actually exists on the exec builder.
  • Fixes a regression introduced by daf19df ("Rename .gpu() to .gpuMemory()"): the workflow source moved to the new method name but the catalog pin stayed on 5.13.1, where the builder only exposes .gpu(). Every run failed with cannot get element from strictMap: key "gpuMemory" not found.
  • Stops at 5.24.0 deliberately: 5.25.0 introduces a wasm artefact type that needs a newer @platforma-sdk/tengo-builder than the catalog pins.

Why a separate PR

PR #1 (feat/MILAB-6382-gpu-support) adds exec.hasGpu gating on top of .gpuMemory() — both APIs are unavailable in 5.13.1. Splitting the SDK bump out keeps the regression fix bisectable on its own and lets #1 rebase to pick it up.

Verified

  • pnpm install + env PL_PKG_DEV=local pnpm build — 9/9 tasks OK.
  • Re-ran the block against a v3.5.0 backend with --runner-gpu-available=enabled: the strictMap error is gone. (Hit a separate "Mac path not visible to remote backend" issue at the software-dispatch stage — unrelated to this PR.)

Test plan

  • Pull, pnpm install, pnpm build clean
  • Existing tests pass on CI

Greptile Summary

This PR fixes a regression introduced when daf19df renamed .gpu() to .gpuMemory() in the workflow source but left the catalog pin on @platforma-sdk/workflow-tengo@5.13.1, which only exposes the old method name. The bump to 5.24.0 (deliberately stopping before 5.25.0 to avoid a tengo-builder compatibility issue) makes the API call match what the runtime provides.

  • pnpm-workspace.yaml: Catalog pin updated 5.13.15.24.0; exact-version pinning style preserved.
  • pnpm-lock.yaml: Lock file regenerated; transitive dependency software-ptabler advances 1.15.01.16.1 as part of the new resolution graph.
  • .changeset/sdk-bump-gpumemory.md: New changeset entry correctly classifies this as a patch release of the workflow package.

Confidence Score: 5/5

Safe to merge — the change is a focused catalog bump that directly unblocks the renamed .gpuMemory() call; the version ceiling is documented and intentional.

The only changed code is the catalog pin and its generated lock file. The workflow's use of .gpuMemory() is confirmed in main.tpl.tengo; the bump brings the SDK in line with that call. The transitive software-ptabler bump is a minor patch-level advance with no interface changes visible in this diff. The decision to stop at 5.24.0 is clearly explained in both the PR description and the changeset.

No files require special attention.

Important Files Changed

Filename Overview
pnpm-workspace.yaml Catalog pin for @platforma-sdk/workflow-tengo bumped from 5.13.1 → 5.24.0 to expose .gpuMemory() at runtime; intentionally stops before 5.25.0 to avoid a wasm artefact type dependency mismatch.
pnpm-lock.yaml Lock file updated to reflect the catalog change; transitive dependency @platforma-open/milaboratories.software-ptabler moved from 1.15.0 → 1.16.1 as part of the new resolution; integrity hashes are present for both packages.
.changeset/sdk-bump-gpumemory.md New changeset entry marking the workflow package as a patch bump — correct classification for a regression fix.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["workflow/src/main.tpl.tengo\nb.gpuMemory(args.gpuMemory)"] -->|"requires"| B["@platforma-sdk/workflow-tengo"]
    B -->|"before: 5.13.1\n❌ only exposes .gpu()"| C["Runtime error:\ncannot get element from strictMap:\nkey 'gpuMemory' not found"]
    B -->|"after: 5.24.0\n✅ exposes .gpuMemory()"| D["Block runs successfully"]
    B -->|"skipped: 5.25.0+"| E["Requires newer tengo-builder\n(not pinned in catalog yet)"]
    B --> F["Transitive: software-ptabler\n1.15.0 → 1.16.1"]
Loading

Reviews (1): Last reviewed commit: "MILAB-6382: bump workflow-tengo to 5.24...." | Re-trigger Greptile

The workflow was updated in daf19df (April 24, "Rename .gpu() to
.gpuMemory()") but the catalog pin stayed on @platforma-sdk/workflow-tengo
5.13.1, where the exec builder only exposes .gpu(). Every block run failed
with "cannot get element from strictMap: key 'gpuMemory' not found" at the
b.gpuMemory(...) call.

5.24.0 is the highest version that builds cleanly against the existing
@platforma-sdk/tengo-builder 2.4.18 (5.25.0 adds a wasm artefact type that
the older tengo-builder does not understand).

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Code Review

This pull request bumps the @platforma-sdk/workflow-tengo package from version 5.13.1 to 5.24.0 in both pnpm-workspace.yaml and pnpm-lock.yaml to resolve a runtime issue where the .gpuMemory() method was missing. It also updates the dependency @platforma-open/milaboratories.software-ptabler to version 1.16.1 and adds a corresponding changeset file. There are no review comments, and I have no feedback to provide.

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.

@blackcat
blackcat marked this pull request as ready for review June 5, 2026 09:48
CI's infrastructure-package check rejected the older versions:

  @platforma-sdk/block-tools     2.7.2  -> 2.10.6
  @platforma-sdk/tengo-builder   2.4.18 -> 4.0.5

Build verified locally: pnpm install + env PL_PKG_DEV=local pnpm build
both clean (9/9 tasks OK).
@blackcat
blackcat merged commit ff8fe36 into main Jun 5, 2026
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants