Skip to content

fix: two things a fresh install trips over - #3

Merged
SeeRay11 merged 2 commits into
devfrom
install-fixes
Aug 24, 2026
Merged

fix: two things a fresh install trips over#3
SeeRay11 merged 2 commits into
devfrom
install-fixes

Conversation

@SeeRay11

@SeeRay11 SeeRay11 commented Aug 24, 2026

Copy link
Copy Markdown
Owner

Issue for this PR

Closes #

Type of change

  • Bug fix
  • New feature
  • Refactor / code improvement
  • Documentation

What does this PR do?

Two things a fresh install trips over, found by wiping OpenFlow off a Windows machine and reinstalling strictly from the README.

1. Stale bun.lock. The lockfile recorded packages/flow at 0.1.0; packages/flow/package.json says 1.1.0. The lock was last committed at d0b63fca2 (v1.0.0) and the version bump never regenerated it. So bun install on a clean clone rewrites it — every new checkout is dirty before you touch anything — and bun install --frozen-lockfile fails. Regenerating the lock is the whole fix; the diff is one line.

2. database is locked is undocumented. "Stop anything already running" treats a leftover run as a port problem. It is not always one. Every opencode engine opens the same database in the opencode data directory, and a second engine — another clone, or one a previous launcher left behind — can hold that database without holding either port. The engine then dies with

[engine] Error: Unexpected error
[engine] database is locked

Freeing 4096/5174 does not help, because the offending engine may not be on them. The section now names the symptom and stops the engine by what it is running instead of by port, with a PowerShell and a pkill -f recipe. Added to the English README and the 21 translations.

How did you verify your code works?

  • bun install --frozen-lockfile exits 0 on the regenerated lock (it failed before), and git status is clean after a fresh bun install.
  • The stale-lock problem reproduced in two independent clones on this machine.
  • Both stop-by-process recipes were run against live processes: the filter matched the launcher (bun openflow.ts), the engine, and the vite child. Matching all three matters — killing only the engine lets the launcher respawn it, which is how the original failure kept coming back.
  • Full path re-run afterwards: clone, bun install, bun openflow.ts, engine on 4096, canvas on 5174, provider catalog loads.

Screenshots / recordings

Not a UI change.

Checklist

  • I have tested my changes locally
  • I have not included unrelated changes in this PR

SeeRay11 and others added 2 commits August 23, 2026 19:46
The committed lockfile still recorded packages/flow at 0.1.0, so `bun install`
on a fresh clone rewrote it and left every new checkout with a dirty tree —
and `bun install --frozen-lockfile` failed outright.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Stopping a previous run is documented as a port problem, but a second opencode
engine — another clone, or one a previous launcher left behind — shares the one
database in the opencode data directory without necessarily holding either port.
The engine then dies with `database is locked`, which looks nothing like a port
conflict and is not fixed by freeing them.

Document the symptom and a stop-by-process recipe for PowerShell and POSIX
shells, in the English README and the 21 translations.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@SeeRay11
SeeRay11 merged commit 11b066f into dev Aug 24, 2026
2 checks passed
@SeeRay11
SeeRay11 deleted the install-fixes branch August 24, 2026 02:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant