Skip to content
Latchkey

Deno "Failed reading lock file" / integrity mismatch in CI

Deno compares the content it fetched against the hashes stored in deno.lock. When they differ, or the lockfile cannot be read or is out of date, Deno stops rather than run unverified code.

What this error means

The run fails with "error: Failed reading lock file" or "The lockfile is corrupt" / "Integrity check failed for ... Cache has ... but lockfile expects ...".

deno
error: The lockfile is out of date. Run `deno cache --lock=deno.lock --lock-write` or
    Integrity check failed for https://jsr.io/@std/assert/1.0.0/mod.ts
    Cache has "abc123..." but lockfile expects "def456..."

Common causes

The lockfile drifted from the dependencies

Imports or versions changed without regenerating deno.lock, so the recorded hashes no longer match what resolves.

A dependency was republished with different content

A remote or registry artifact changed under the same URL/version, producing a hash that differs from the pinned one.

How to fix it

Regenerate and commit the lockfile

  1. Refresh the lockfile so it matches the current dependency graph.
  2. Review the diff to confirm the change is expected.
  3. Commit deno.lock so CI verifies against it.
Terminal
deno cache --reload --lock=deno.lock --lock-write main.ts

Verify against the lockfile in CI

Have CI enforce the lockfile so drift fails fast rather than silently re-resolving.

Terminal
deno cache --frozen --lock=deno.lock main.ts

How to prevent it

  • Regenerate deno.lock whenever imports or versions change.
  • Commit the lockfile and enforce it with --frozen in CI.
  • Pin remote specifiers so their content cannot shift under you.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →