Difficult bugs · inherited code · integrations · production failures

Difficult software problems. Evidence before claims.

Every repair published here has a reproduced failure, an implemented change and verification evidence. Investigations, no-go outcomes and unverified theories stay off this page.

See recent verified fixes ↓Give us a problem →

Recent Fix Factory work

Verified fixes with public engineering evidence.

The public record shows the defect, the repair and the evidence. Our internal investigation workflow, prompts and triage method stay private.

Publication rule: only work that has crossed the full line from reproduction to implemented repair to verification is shown here. Upstream merge status is reported separately from local verification.

Stripe Terminal React Native #1140 — intent-cache concurrency

Status: VERIFIED FIX ACCEPTED / MERGED.

Broken: the Android React Native bridge used ordinary mutable intent caches across code paths that can run concurrently.

Repair: synchronise the cache maps while preserving the surrounding bridge behaviour and add focused regression coverage.

Verification: focused concurrency test 5/5 and stable across 10 runs; Android unit suite 233/233; JavaScript 238/238; iOS 166/166; clean diff check. Verification was JVM/unit-test level rather than a physical-device reproduction.

Upstream outcome: Stripe collaborator review: APPROVED — “LGTM”. The PR was merged on 2 October 2026.

Public provenance: stripe/stripe-terminal-react-native PR #1140. Authored by kevhoward20011-oss / HelpfulCo Innovations Ltd.

Google go-jsonnet #484 — post-fork deadlock

Status: VERIFIED REPAIR / UPSTREAM ADOPTION PENDING.

Broken: after the Go runtime was initialised in a parent process, a Linux fork() child could enter inherited runtime state whose supporting threads no longer existed and hang indefinitely.

Repair: detect the unsafe post-fork process state before entering jsonnet_make() and fail immediately with an actionable error rather than entering an unrecoverable runtime state.

Verification: unpatched Linux case hung for 300+ seconds; repaired path fails immediately. Regression matrix 4/4; Python 14/14 on Linux and macOS; C-bindings compatibility 31/31; go test ./... reported no failures; normal evaluation and spawn paths passed.

Public provenance: HelpfulCo public technical submission on google/go-jsonnet #484. The upstream issue remains open, so this is not presented as an accepted Google patch.

Cloudflare Pingora #931 / PR #1037 — cancelled cache lookup stale lock

Status: VERIFIED REPAIR / UPSTREAM PR OPEN.

Broken: cancelling a cache-miss writer while its user lookup future was pending could leave a zero-permit per-key cache lock installed. Later requests for the same key could then remain blocked indefinitely.

Repair: tie lock cleanup to an ownership guard whose Drop path releases only the exact lock instance it owns, including when the future is cancelled while awaiting the user lookup.

Verification: the stale-lock failure was reproduced on the pre-patch implementation; the cancellation regression passes with the repair; the relevant pingora-memory-cache test suite passes; clean diff check passes. Additional regression coverage confirms stale cleanup cannot remove a newer writer's lock and normal completion still releases its own lock.

Upstream status: PR #1037 is open and mergeable. The Hub claims the reproduced-and-verified repair only, not upstream acceptance.

Public provenance: cloudflare/pingora issue #931 · HelpfulCo PR #1037.

Hedera Guardian VM0010 #5941 — Eq. (7) BCEF_R parameter

Status: VERIFIED REPAIR / UPSTREAM PR OPEN.

Broken: the Section 8.1.2 Equation (7) implementation and schema path needed to represent BCEF_R as the methodology's distinct positive biomass conversion and expansion multiplier, without incorrectly applying the CF_j upper bound to it.

Repair: wire bcefR consistently through the calculation logic, input/output schemas and documentation while preserving CF_j as a separate factor bounded to (0,1].

Verification: focused post-commit Node test 9/9 PASS; independent hand-computation check included; BCEF_R > 0 and not capped at 1; CF_j remains bounded to (0,1]; commit contains exactly the five authorised VM0010 files. ACM0010 and CLEAR were untouched.

Submission: commit 06ad4499aa41f8d4620764ddd1e17f812cb5c07b, message fix(vm0010): correct Eq. (7) BCEF_R parameter, is submitted upstream in Guardian PR #7107.

Public provenance: hashgraph/guardian issue #5941 — VM0010 v1.4 · HelpfulCo PR #7107. Upstream acceptance is not claimed while the PR remains open.

What counts as verified here

Failure reproduced — the reported behaviour has been demonstrated.
Repair implemented — a bounded code change exists.
Regression evidence — the repaired path is exercised by tests or repeatable checks.
Compatibility checked — relevant surrounding behaviour is checked where practical.
Upstream status stated separately — local verification is never presented as maintainer acceptance.

Why the distinction matters

A promising diagnosis is not a fix. A patch that has not survived verification is not a fix. And a locally verified repair is not the same as an upstream merge.

We do not turn “looks right” into “fixed”.

Verified repair evidence

Completed cases with reproduced failure, implemented repair and verification.

Historical benchmark work is explicitly labelled. No investigation-only or no-go entries appear in this portfolio.

Next.js #85416 — request-body race

Status: verified independent repair of a historical upstream bug.

Broken: a timing-dependent request-body race could leave a downstream Server Action with incomplete JSON.

Impact: production-style requests could fail even though the same path sometimes appeared healthy.

Our verification: repaired independently and stress-verified: 15/15 final requests successful, a 7.2 MB slow-streamed request returned 200, and static checks were clean.

Public provenance: vercel/next.js issue #85416. The upstream issue had already been fixed by Next.js in PR #85418. This portfolio case claims independent reproduction, repair and verification only — not authorship of the upstream fix.

Google Gson — historical TaRBench repair

Status: verified historical benchmark repair, not an open Google Gson issue.

Broken: the reconstructed historical UnsafeAllocatorInstantiationTest#testAbstractClassInstantiation case contained assertion behaviour that was later corrected upstream as part of Gson's Error Prone cleanup.

Our verification: the focused repaired test completed with 1 test run, 0 failures, 0 errors and Maven BUILD SUCCESS on 27 September 2026.

Public provenance: the relevant upstream change is present in google/gson commit dc20b756. This case is presented only as a historical benchmark reconstruction and independently verified repair.

Sonar CXX #1203 — executable-line calculation

Status: verified independent repair of a historical Sonar CXX executable-lines defect.

Broken: CxxFileLinesVisitor could count AST nodes outside the intended function-body scope as executable lines, producing incorrect coverage calculations.

Our verification: the focused CxxFileLinesVisitorTest#TestExecutableLinesOfCode repair was verified under the era-appropriate Temurin Java 8 runtime: 1 test run, 0 failures, 0 errors, 0 skipped; Cxx :: Sensors SUCCESS; Maven BUILD SUCCESS on 29 September 2026.

Public provenance: SonarOpenCommunity/sonar-cxx issue #1203. The original upstream issue was completed in 2017. This portfolio case claims independent reconstruction, repair and verification only — not authorship of the upstream fix.

go-jsonnet #484 — Python binding post-fork deadlock

Status: verified independent repair of the reproduced deadlock behaviour; upstream issue remains open.

Broken: after the Go runtime was initialised in a parent process, a Linux fork() child could enter jsonnet_make() with inherited runtime state whose supporting threads no longer existed. The result was a deterministic 0%-CPU hang.

Repair: detect the unsafe post-fork process state before entering jsonnet_make(), then fail immediately with an actionable error.

Our verification: unpatched Linux case hung for 300+ seconds; repaired path fails immediately. Regression matrix 4/4; full Python suite 14/14 on Linux and macOS; C-bindings compatibility 31/31; go test ./... reported no failures; normal evaluate_snippet, evaluate_file, spawn and parent-process operation all passed. No public ABI change.

Environment lesson: macOS alone produced a false pass because the inherited Go runtime state differed. Linux verification exposed the earlier jsonnet_make() deadlock, so the final defence was moved ahead of that call.

Public provenance: google/go-jsonnet issue #484. HelpfulCo's claim is limited to independent reproduction, repair and verification of the observed deadlock behaviour in the tested environments.

Stripe Terminal React Native #1140 — concurrent intent caches

Status: verified HelpfulCo fix, reviewed by Stripe and merged upstream.

Broken: in-memory PaymentIntent and SetupIntent caches in the Android React Native bridge were backed by ordinary mutable maps while bridge calls and Stripe SDK callbacks can access lifecycle state concurrently.

Repair: use synchronised map wrappers and preserve the surrounding behaviour, with focused regression coverage for concurrent access.

Our verification: focused test 5/5 passing and stable across 10 consecutive runs; Android 233/233; JavaScript 238/238; iOS 166/166; clean diff check. Stripe collaborator review approved the PR with “LGTM”, and it was merged.

Scope: this claim is limited to the reproduced Android React Native bridge cache-concurrency defect. It does not claim to fix the separate native Android #747 issue, and no analogous iOS defect was reproduced.

Public provenance: stripe/stripe-terminal-react-native PR #1140.

Cloudflare Pingora #931 — cancellation-safe cache-lock cleanup

Status: verified HelpfulCo repair; PR #1037 remains open upstream.

Broken: a cancelled cache-miss writer could leave its per-key coalescing lock behind with zero permits while the user lookup was still pending, blocking later same-key requests.

Repair: introduce a cancellation-safe ownership guard whose Drop path wakes waiters and removes only the lock instance owned by that writer.

Our verification: pre-patch stale-lock behaviour reproduced; repaired cancellation regression passes; relevant pingora-memory-cache test suite passes; clean diff check passes; dedicated coverage confirms an old guard cannot remove a newer writer's lock and that a normally completing writer still releases its own lock.

Public provenance: cloudflare/pingora issue #931 · PR #1037. Upstream acceptance is not claimed while the PR remains open.

Hedera Guardian VM0010 #5941 — Equation (7) BCEF_R correction

Status: verified HelpfulCo repair; PR #7107 is open upstream.

Defect: VM0010 v1.4 Section 8.1.2 Equation (7) required a consistent BCEF_R parameter path across calculation logic and schemas. BCEF_R is a positive biomass conversion and expansion multiplier and must not inherit the (0,1] bound that belongs to CF_j.

Repair: use bcefR in the Eq. (7) calculation, require and expose it consistently in the relevant schemas, and document the correction in the VM0010 README slice.

Our verification: focused post-commit suite 9/9 PASS; Eq. (7) matches independent hand-computation; BCEF_R is validated as > 0 and is not capped at 1; CF_j remains bounded to (0,1]. The final commit contains exactly five authorised VM0010 files, with no ACM0010 or CLEAR changes and no unrelated files committed.

Submitted commit: 06ad4499aa41f8d4620764ddd1e17f812cb5c07b is now upstream in PR #7107. The Hub claims the verified repair and submission only, not maintainer acceptance or bounty award.

Public provenance: hashgraph/guardian issue #5941 — VM0010: Improved Forest Management, Conversion from Logged to Protected Forest (v1.4) · HelpfulCo PR #7107.

Publication rule: the Engineering Hub reserves “fixed” for outcomes with defensible verification. If work has not reached that standard, it is not listed here.

Software rescue

Your engineers know the system. Bring us the problem that is consuming their time.

Fix Factory is designed as an escalation route for stubborn defects: difficult, intermittent, cross-stack or simply too expensive to keep circling internally.

Good problems to send

A bug that keeps coming back.
An app or AI-built project that is nearly working but stuck.
An API, database or integration failure.
A release-only or environment-specific failure.
Inherited code nobody wants to touch.
A difficult public issue your team has not had time to solve.

What you get

A focused investigation of the actual failure.
A repair where the evidence supports one.
Verification showing what now works.
A clearly stated limitation where part of the final environment is outside our control.

No inflated claims. No mystery “AI says it works” hand-off.

Send us your software problem →Back to Engineering Hub