sync plugin OOMs ("memory allocation of N bytes failed") when the target canister already has assets

使用提供的 icp.yaml 以及两个命令 icp deploy 或 icp sync 重现该问题，并比较空 canister 与已填充的 canister。首先跟踪 sync 插件路径和 certified-assets migration-v2.2.1 插件；确定故障属于 icp-cli 还是插件。完成的标准是：已填充的 canister 能够同步已更改的 asset，而不会耗尽内存或数分钟没有任何反应。

Summary

A plugin sync step against a canister that already holds assets exhausts the plugin sandbox's memory and aborts with memory allocation of 44 bytes failed, after ~7 minutes during which it produces no output. The same sync against an empty canister completes in 3–8 seconds.

The practical effect is that an asset canister can be deployed once and then never updated: every subsequent icp deploy / icp sync fails.

Environment

Reproduction

icp.yaml:

canisters:
  - name: docs
    recipe:
      type: "@dfinity/[email protected]"
      sha256: ee41744bd1361593a041d830b06ce50598cae5b21b57209fc727e8f63ae7e906
      configuration:
        version: "0.29.1"
        dir: docs/build          # any static site; ours is ~230 files / 4.4 MB
        build:
          - npm run build-docs
networks:
  - name: local
    mode: managed
    version: 15.0.0-2026-07-31-04-23

icp network start --background -e local

icp deploy docs -e local -y   # 1st: creates the canister, syncs 230 assets — OK, ~8s
icp deploy docs -e local -y   # 2nd: fails

icp sync docs -e local on its own reproduces it identically, so it is the sync step alone — no build, install or upgrade involved.

Actual

DEBUG icp::progress: sync plugin (legacy assetstorage / .ic-assets.json5): starting for canister <id> (environment: local)
DEBUG icp::progress: api_version: 2
DEBUG icp::progress: found 230 file(s) from ["docs/build"]
                    <~7 minutes, no output>
ERROR icp::operations::sync: ----- Failed to sync canister 'docs': <id> -----
ERROR icp::operations::sync: 'failed to run plugin'
ERROR icp::operations::sync:   caused by: plugin returned error: memory allocation of 44 bytes failed
ERROR icp::operations::sync:   note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: Canister(s) ["docs"] failed to sync.

Expected

The sync completes, uploading only the changed assets — as it does when the canister is empty.

Notes

• Empty vs populated is the trigger. First deploy (fresh canister, list returns nothing): 230 assets in 3–8s. Second: OOM. Clearing the canister restores the fast path — icp canister call docs clear '(record {})' followed by icp sync docs -e local uploads all 230 assets in 3 seconds. That is the only workaround we found, and it is not usable in production, since the canister serves nothing between the clear and the commit.

• Not an icp-cli version issue. 1.3.0 behaves identically; the plugin comes from the pinned recipe, not from the CLI.

• Moving to the current plugin does not help. certified-assets v0.3.3 (plugin-release.wasm) calls a can_sync query, which the legacy dfx assetstorage canister does not export, so it fails with IC0536 … has no query method 'can_sync'. The migration-* plugin appears to be the only one supporting these canisters, and it is the one that OOMs.

• The memory limit is not configurable. ICP_CLI_PLUGIN_COMPUTE_LIMIT_SECS exists (#669) but there is no memory equivalent, so the ceiling cannot be raised from the outside. If the allocation ceiling is a deliberate sandbox guard rather than a leak, the same argument as #669 applies — it cannot be calibrated for someone else's asset bundle.

• The silent ~7 minutes is its own problem. With no progress output, a hang and slow work are indistinguishable; in CI this consumed a 45-minute job timeout before failing.

• Possibly related: dfinity/certified-assets#71, which tracks the legacy assetstorage migration plugin. If the fault is in the plugin rather than the sandbox, this may belong there instead.

Related, but separate

On a redeploy, icp deploy upgrades the canister (which stops it) and runs the sync step before restarting it, so the sync's first call is rejected with IC0508 … is stopped and therefore does not have a CallContextManager. A failed deploy also leaves the canister stopped — easy to miss on an asset canister, because http_request is a query and keeps serving normally while every update call is rejected. Happy to file that separately if you'd prefer it tracked on its own.