open source

the qcom backend bound kernel buffers by compact signature slot instead of by the call's globals, so a kernel that only used buffers 0 and 2 got buffer 1 where 2 should have been. t[1] += 2 then t[1] -= 1 came out as [[0, 1], [4, 5]]. found it on a mock qcom device.

TRUNC had no backward pass, so any gradient flowing through it was dropped silently rather than erroring. four lines.

the cuda toolchain version was missing from the compile cache key, so a toolchain upgrade served stale kernels.

nan propagating out of the inactive branch of a where, through sqrt backward.

i filed the issue first, then sent the pin that fixed it.

a retrieval against an empty profile returned an error instead of an empty result, so every first-time user looked like a failure rather than a cold start.

synthetic bolt relationship ids collided with the real id range.

the query optimizer returns different rows depending on which direction it expands the plan. this is the differential test that pins both orders to the same result.

randomised differential tests over the sparse traversal kernels.

the sparse kernels disagree on a zero-hop start that has no edges.

one high-degree vertex could blow the whole result budget, because the cap was on vertices and not on rows.

two different tag sets serialise to the same cache key. that key is both the on-disk filename and the remote object key, so one entry silently reads back as another.

request-trace header capture matched only exact keys, so prefixed headers were missed and sensitive ones could not be excluded. nvidia's inference runtime, rust.

the neon and scalar distance kernels disagree on 38% of random vector pairs at 22 dimensions and 93% at 1536, worst case 30 ulp. the existing equivalence test fed them integers, where every intermediate is exactly representable, so it agreed bit for bit and could not fail. i confirmed the replacement can fail by tightening its tolerance until it did.

proved the louvain modularity test could not fail. injected one bug, then made the old whole-phase test pass and a new per-move test fail on the same bug.

net minus 109 lines. the build stopped needing openssl on the host at all.

the fix for the one above. substring cast start and length straight into the offset type, so on the 32 bit arms a start past 2^31 wrapped negative and got read as counting from the end of the value. the call did not fail, it quietly did something else. the length cast turned out to be wrong on all four arms, not just the 32 bit ones, because u64::MAX as i64 is -1.

substring wraps start and length to i32 on Utf8 but not on LargeUtf8. same call, same data, different answer depending on which offset width the array happens to use.

concat narrowed the combined value length with an unchecked `as i32`, so a caller-controlled element width wrapped negative. the fallible pattern it needed was already in use directly above it in the same function.

pinned the bincode variant index for the v3 cache keys, so reordering an enum cannot silently reinterpret data already written to disk.

\u{...} escapes were being dropped in HIR string and char literals.

the integer ** operator crashed every program that used it.