chore(deps): update fro-bot/agent to v0.107.1 - #892
Merged
Conversation
mrbro-bot
Bot
force-pushed
the
renovate/fro-bot-agent-0.x
branch
from
September 3, 2026 01:15
41f4d32 to
6a6d1a1
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
v0.107.0→v0.107.1Release Notes
fro-bot/agent (fro-bot/agent)
v0.107.1Compare Source
What's new
This patch fixes a self-perpetuating cache failure that could trap a repository in a state where no future run could recover without manual cache deletion, and closes two follow-on correctness gaps discovered during its review.
Bug fixes
A failed OpenCode server bootstrap was persisting poisoned session state that caused every subsequent run to fail the same way. The root cause was deeper than it appeared: the database was never checkpointed before being captured to cache — a hot write-ahead log was being transported instead of a stable snapshot — and a run that declined to save rather than repair the cache left the next run restoring the same bad entry, making non-saving a stable failure mode rather than a recovery path.
The fix repairs the cache on restore, between
restoreCacheand server bootstrap, so a stuck repository heals itself on its first run with session history intact. A WAL checkpoint usingnode:sqlite(available unflagged on Node 24) is now performed insidesaveCachebefore any capture, so every path that persists state inherits the checkpoint structurally. The-shmwal-index file, which SQLite never syncs to disk, is no longer captured and any existing copy is deleted on restore. A configurable bootstrap budget (bounded at two minutes) is reported in the job summary, andsession-retentionnow actually reaches the pruning logic it had been parsed, validated, logged, but never applied. #1519An
@octokit/types16→17 upgrade (pulled transitively by@octokit/auth-appand@octokit/coredependency updates) began modelling GitHub'sFormat: int64fields asnumber | bigint, including the repositoryid. This broke CI becausedatabaseIdis used as a key in the operator redaction deny list, andSet<number>.has(bigint)is always false — meaning a redacted repository could silently stop being denied. Widening the type end-to-end was rejected becauseNumber(id)above 2⁵³ is lossy and could collide with a different repository's key.The fix introduces a single conversion boundary,
toSafeRepositoryId, applied only where a repository id enters the system. An id that cannot round-trip exactly yieldsnulland falls back tonodeId— which is the deny list's primary key, with the numeric id as secondary — so a binding keyed only bynodeIdstill denies. The backfill's skip-check and the redaction gate's usability check were also made consistent: previously a malformed stored id looked complete to one and unusable to the other, and was never repaired. #1513Two correctness gaps surfaced during the #1519 review. The port-quiescence probe used a socket timeout to detect that the OpenCode child had exited — but a connect that neither completed nor was refused (the timeout case) resolved
finish(false), the same value as a refused connection. "I don't know" was silently becoming "it's fine," suppressing the warning that a checkpoint may have raced a live writer. The probe now keeps polling on an inconclusive result, with only the real 5-second deadline producingquiesced: false. Separately, a mid-transfer failure in the S3 adapter left a partialopencode.dbon disk; if that path also missed the Actions cache, the repair block was skipped entirely and a truncated database reached bootstrap unexamined. The fix unlinks the local path only when the pipeline itself throws — when a partial write actually occurred — leaving pre-existing files untouched on any rejection before the stream opened. #1521Full changelog
0.107.1 (2026-09-02)
Bug Fixes
Documentation
Continuous Integration
Configuration
📅 Schedule: (in timezone America/Phoenix)
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate CLI.