Incorrect built-in Math constants in edge-runtime v1.74.3; Math.LN10 also wrong in v1.74.2 (linux/amd64)

[raf-master]

Bug report

Several native JavaScript Math.* constants return incorrect values inside supabase/edge-runtime:v1.74.3.

The issue reproduces with a single dependency-free TypeScript file. The equivalent probe returns the expected values in the official Deno 2.1.4 container.

Math.LN10 was also independently reproduced as incorrect in edge-runtime v1.74.2, including after deleting and cleanly pulling the same image digest.

Environment

• Docker Desktop Server: 28.3.2
• Docker operating system: Linux
• Docker host architecture: x86_64
• Kernel: 6.6.87.2-microsoft-standard-WSL2
• Supabase CLI: 2.109.1
• Control image: denoland/deno:2.1.4

Deno control:

• Deno 2.1.4
• V8 13.0.245.12-rusty
• Target x86_64-unknown-linux-gnu

Edge Runtime v1.74.3:

• Image: public.ecr.aws/supabase/edge-runtime:v1.74.3
• Image ID: sha256:c52405002a890ca9fcf77978671c57f3a988e03174afb277f84ac65bc917013c
• RepoDigest: public.ecr.aws/supabase/edge-runtime@sha256:c52405002a890ca9fcf77978671c57f3a988e03174afb277f84ac65bc917013c
• Architecture: amd64
• OS: linux
• Created: 2026-07-31T04:09:03.225642475Z
• Runtime reports:
  • edge-runtime 0.1.0
  • deno 2.1.4 (release, x86_64-unknown-linux-gnu)

Additional v1.74.2 evidence:

• Image: public.ecr.aws/supabase/edge-runtime:v1.74.2
• Digest: sha256:a82676277615aee03c4f288cbbbf68dedb5ba8693073e567ab8dbfdd11ba5d45
• Architecture: amd64/linux

No application or Supabase environment variables were passed to the isolated v1.74.3 reproducer.

Minimal reproduction

Create <temp-dir>/index.ts:

function bits(value: number): string {
  const buffer = new ArrayBuffer(8);
  new DataView(buffer).setFloat64(0, value, false);

  return Array.from(new Uint8Array(buffer))
    .map((b) => b.toString(16).padStart(2, "0"))
    .join("");
}

const constants = {
  E: Math.E,
  LN2: Math.LN2,
  LN10: Math.LN10,
  LOG2E: Math.LOG2E,
  LOG10E: Math.LOG10E,
  PI: Math.PI,
  SQRT1_2: Math.SQRT1_2,
  SQRT2: Math.SQRT2,
};

Deno.serve(() =>
  Response.json(
    Object.fromEntries(
      Object.entries(constants).map(([name, value]) => [
        name,
        {
          value: value.toPrecision(17),
          bits: bits(value),
        },
      ]),
    ),
  ),
);

Replace <temp-dir> below with its absolute host path.

docker pull public.ecr.aws/supabase/edge-runtime:v1.74.3
docker run -d --rm --name edge-math-runtime-1743-repro --mount type=bind,source=<temp-dir>,target=/probe,readonly -p 127.0.0.1::9000 public.ecr.aws/supabase/edge-runtime:v1.74.3 start --main-service=/probe --port=9000 --policy=per_worker
docker port edge-math-runtime-1743-repro 9000/tcp
curl http://127.0.0.1:<edge-host-port>/
docker stop edge-math-runtime-1743-repro

No dependency installation is necessary.

Expected behavior

The built-in constants should match standard JavaScript/Deno values and IEEE-754 representations:

Constant	Expected value	Expected bits
Math.E	2.7182818284590451	4005bf0a8b145769
Math.LN2	0.69314718055994529	3fe62e42fefa39ef
Math.LN10	2.3025850929940459	40026bb1bbb55516
Math.LOG2E	1.4426950408889634	3ff71547652b82fe
Math.LOG10E	0.43429448190325182	3fdbcb7b1526e50e
Math.PI	3.1415926535897931	400921fb54442d18
Math.SQRT1_2	0.70710678118654757	3fe6a09e667f3bcd
Math.SQRT2	1.4142135623730951	3ff6a09e667f3bcd

Actual behavior

Edge Runtime v1.74.3 returns:

Constant	Actual value	Actual bits
Math.E	2.0000000000000000	4000000000000000
Math.LN2	0.0000000000000000	0000000000000000
Math.LN10	2.0000000000000000	4000000000000000
Math.LOG2E	1.0000000000000000	3ff0000000000000
Math.LOG10E	0.0000000000000000	0000000000000000
Math.PI	3.1415926535897931	400921fb54442d18
Math.SQRT1_2	0.70710678118654757	3fe6a09e667f3bcd
Math.SQRT2	1.4142135623730951	3ff6a09e667f3bcd

Control

Run the same index.ts with Deno 2.1.4:

docker run -d --rm --name edge-math-deno-control --mount type=bind,source=<temp-dir>,target=/probe,readonly -p 127.0.0.1::8000 denoland/deno:2.1.4 deno run --allow-net /probe/index.ts
docker port edge-math-deno-control 8000/tcp
curl http://127.0.0.1:<deno-host-port>/
docker stop edge-math-deno-control

The Deno control returns every expected value and bit pattern.

Additional evidence

With Edge Runtime v1.74.2:

• Math.LN10 returned 2.0000000000000000
• Actual bits: 4000000000000000
• Expected bits: 40026bb1bbb55516

The v1.74.2 image was deleted and cleanly pulled again. The pulled image had the same expected digest and reproduced the same incorrect result.

This refutes a simple local image/cache corruption explanation.

Impact

Code performing mathematical operations may silently receive incorrect built-in constants.

Libraries that validate or use these constants can fail during module initialization or produce incorrect numerical results.

As one observed downstream example, decimal.js-light validates Math.LN10 during initialization and throws when the value does not match. The library is not required for this reproduction.

Notes

• The reproducer contains only native JavaScript/TypeScript.
• No external dependency is imported.
• No database, secrets, application environment, or application code is involved.
• The exact internal cause has not been established.
• V8 snapshot corruption, serialization, Docker Desktop/WSL2 behavior, Windows-host specificity, or a deno_core/V8 issue remain hypotheses only.
• Reproduction on a native Linux host has not yet been tested.

[raf-master]

Additional reproduction: GitHub Actions Ubuntu runner

I reproduced the same issue on an independent GitHub-hosted Ubuntu runner, outside my original Windows / WSL2 / Docker Desktop environment.

Public reproducer repository:

https://github.com/raf-master/edge-runtime-math-linux-control

GitHub Actions run:

https://github.com/raf-master/edge-runtime-math-linux-control/actions/runs/33109361743

Environment:

• GitHub-hosted runner
• Ubuntu 24.04.4 LTS
• Kernel: 6.17.0-1022-azure
• Architecture: x86_64
• Docker Engine: 28.0.4
• Docker OS/Arch: linux/amd64

Edge Runtime image:

public.ecr.aws/supabase/edge-runtime:v1.74.3

RepoDigest:

sha256:c52405002a890ca9fcf77978671c57f3a988e03174afb277f84ac65bc917013c

Control:

denoland/deno:2.1.4

The Deno 2.1.4 control returned all 8 expected values and IEEE-754 bit patterns.

The Edge Runtime returned exactly the same incorrect values previously observed:

Constant	Expected	Edge Runtime
Math.E	2.7182818284590451	2.0000000000000000
Math.LN2	0.69314718055994529	0.0000000000000000
Math.LN10	2.3025850929940459	2.0000000000000000
Math.LOG2E	1.4426950408889634	1.0000000000000000
Math.LOG10E	0.43429448190325182	0.0000000000000000
Math.PI	3.1415926535897931	correct
Math.SQRT1_2	0.70710678118654757	correct
Math.SQRT2	1.4142135623730951	correct

The reproducer classified the result as:

CASE_LINUX_FAIL_SAME

This means the failure is not specific to my original Windows/WSL2/Docker Desktop host. It reproduces on an independent Ubuntu Linux VM using Docker Engine.

This still does not establish the internal root cause, and I have not tested bare-metal Linux. V8 snapshot/serialization/deno_core remain hypotheses only.

[da1suk8]

I can add three data points that narrow this down considerably.

TL;DR: the corruption is specific to the linux/amd64 image, the five broken constants are exactly the five that V8 computes at heap-genesis time (vs. the three installed from literals / hardware sqrt), and in edge-runtime those genesis values are frozen into the binary at build time by the startup snapshot. So this looks like a corrupted build-time snapshot in the amd64 release lane, not a runtime or user-environment issue.

1. The linux/arm64 variant of the same tag is clean

I ran the unmodified reproducer from the OP against both platform variants of public.ecr.aws/supabase/edge-runtime:v1.74.3 (digest sha256:c52405002a890ca9fcf77978671c57f3a988e03174afb277f84ac65bc917013c, matching the digest cited above) on the same machine (Docker Desktop, Apple Silicon):

variant	execution	result
linux/arm64	native	all 8 constants correct, bit-exact
linux/amd64	emulated	broken exactly as reported — same bit patterns (4000000000000000, 0000000000000000, 4000000000000000, 3ff0000000000000, 0000000000000000); PI/SQRT1_2/SQRT2 intact

The emulated amd64 run reproduces bit-for-bit what was already measured on native x86_64 (including the GitHub-hosted runner repro above), so emulation isn't a factor; the arm64-native result is the new information.

Additionally, building current main from source natively (macOS arm64, debug) yields all-correct values — the source itself looks fine.

2. The broken/intact split matches V8's genesis code exactly

Bit-level, each broken value is the true value truncated toward zero to an integer, as a float64: e→2.0, ln2→0.0, ln10→2.0, log2(e)→1.0, log10(e)→0.0. Exponents ≥ 1 survive as the truncated integer, values < 1 collapse to +0 — i.e. a clean float→integer→float roundtrip of the computed result, not a bit-masking pattern.

V8 13.0.245.12 installs the Math constants like this (bootstrapper.cc#3679):

double const kE = base::ieee754::exp(1.0);
double const kPI = 3.1415926535897932;
InstallConstant(isolate_, math, "E", factory->NewNumber(kE));
InstallConstant(isolate_, math, "LN10", factory->NewNumber(base::ieee754::log(10.0)));
InstallConstant(isolate_, math, "LN2", factory->NewNumber(base::ieee754::log(2.0)));
InstallConstant(isolate_, math, "LOG10E", factory->NewNumber(base::ieee754::log10(kE)));
InstallConstant(isolate_, math, "LOG2E", factory->NewNumber(base::ieee754::log2(kE)));
InstallConstant(isolate_, math, "PI", factory->NewNumber(kPI));
InstallConstant(isolate_, math, "SQRT1_2", factory->NewNumber(std::sqrt(0.5)));
InstallConstant(isolate_, math, "SQRT2", factory->NewNumber(std::sqrt(2.0)));

Broken set == the base::ieee754::* computations; intact set == the literal + hardware sqrt. That split is hard to explain by anything at request time, and easy to explain if the genesis-time computation (or its serialized result) was corrupted once.

3. Genesis runs on the release builder, and its output ships in the binary

edge-runtime bakes its own V8 startup snapshot at build time (crates/base/build.rs → deno_core::snapshot::create_snapshot), and workers boot from that snapshot. So Math.* in production reflects whatever the machine that built the release computed. This fits all the symptoms: stable across clean pulls of the same digest (it's inside the binary), differing between v1.74.2 (only LN10) and v1.74.3 (five constants), and independent of the user's environment.

As for why only amd64: in .github/workflows/release.yml, the amd64 lane (publish_x86) builds with BuildKit GHA cache (cache-from/cache-to: type=gha) plus the Dockerfile's persistent cargo cache mounts (--mount=type=cache,target=…/target), while the arm64 lane (publish_arm) sets no-cache: true. Since cargo won't re-run build.rs while its outputs look fresh, a once-corrupted snapshot artifact in the cached target dir can keep being linked into subsequent releases — which would also explain the difference in degree between v1.74.2 and v1.74.3. What corrupted the ieee754 results in the first place I can't tell from outside; the caching explains the persistence and the arch asymmetry.

Suggested next steps

1. Rebuild the amd64 image with caches busted (as the arm lane already does) and compare — if a fresh build is clean, that both fixes the shipped images and confirms the poisoned-cache theory.
2. Add a tripwire to crates/base/build.rs: after create_snapshot, boot a runtime from the fresh snapshot and assert the eight Math constants, so a corrupted snapshot can never ship again regardless of root cause.
   fix(build): verify Math constants in runtime snapshot #726
3. To check whether the current CI cache is poisoned: run the x86 lane once with no-cache: true and compare the probe output against the current image.