fix: report portable-store reset recovery failures - #167
Conversation
Return the reset error after a dirty merge so operators see the failure that actually prevented recovery. Cover both recovery branches and preserve the portable runner's sanitized error classification. Adapted from the diagnostic correction in #164; the initial clone already has an operation-wide deadline on current main. Co-authored-by: Sebastien Tardif <sebtardif@ncf.ca>
|
🦞👀 Pull request received. I will update this pull request when review starts. |
|
Codex review: needs maintainer review before merge. Reviewed August 31, 2026, 2:12 AM ET / 06:12 UTC. ClawSweeper reviewWhat this changesThe branch makes portable-store initialization return a failed hard-reset error instead of the earlier dirty-merge error, and adds regression coverage plus operator documentation. Regression provenancePossible regression — probable (reviewed change; reproduction). No predecessor PR is attributed. Merge readinessKeep open: this focused correction fixes a current-main error-propagation defect, with a regression test and supplied real CLI evidence showing the recovery failure is now reported. Priority: P2 Review scores
Verification
How this fits togetherPortable-store initialization prepares a Git-backed SQLite cache for local Gitcrawl use. It validates an existing checkout, attempts a fast-forward update and recovery when necessary, then either makes the validated store available or returns a credential-safe diagnostic. flowchart LR
A[Operator runs portable init] --> B[Existing portable checkout]
B --> C{Can fast-forward?}
C -->|Dirty merge| D[Hard-reset recovery]
D --> E[Sanitized recovery diagnostic]
C -->|Update succeeds| F[Validated portable store]
E --> G[Operator recovery action]
Before merge
Agent review detailsSecurityNone. Review metrics
Technical reviewBest possible solution: Preserve this narrow reset-error propagation so portable-store operators receive the actionable, sanitized failure from the recovery step that actually failed. Do we have a high-confidence way to reproduce the issue? Yes—the supplied macOS real-CLI scenario identifies a current-main baseline error and an after-fix reset failure, and the source shows the exact incorrect return path. Is this the best way to solve the issue? Yes—returning the existing sanitized reset error is the narrowest solution and matches the equivalent earlier recovery branch without changing recovery behavior. AGENTS.md: not found in the target repository. Codex review notes: model internal, reasoning high; reviewed against 7c3e960344df. LabelsLabel changes:
Label justifications:
EvidenceWhat I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
|
What Problem This Solves
Fixes an issue where
gitcrawl init --portable-storerepeats a dirty-merge error when the subsequent reset actually fails. The reported error now comes from the failed recovery operation, preserving the existing credential-safe Git diagnostics and underlying exit status.Why This Change Was Made
This is the current-main diagnostic correction from #164, with regression coverage for both reset paths. The original PR conflicts with the portable-store rewrite; its additional clone timer is omitted because current main already bounds the entire operation to two minutes. Thanks @SebTardif; contributor credit is retained in the commit and changelog.
User Impact
Operators get the actual reset failure, including existing disk-space guidance when applicable, instead of being directed back to the preceding merge conflict. Clone, reset, and data-preservation policies are unchanged.
Evidence
Built and ran the real CLI on macOS against a synthetic SQLite archive and real Git, with no Git executable wrapper in the live proof. A new upstream file collides with a local untracked file; an immutable checkout index prevents the subsequent reset.
Paths are normalized in the command excerpt below. Save the reproducer as
proof-reset.py.The equivalent current-main binary instead reported
Your local changes would be overwritten by merge: exit status 1. The regression test fails on that baseline and checks that both reset paths retain the reset exit code, classified disk-space guidance, and diagnostic redaction.go vet ./...passes. Codex autoreview of the complete change is clean, with no actionable findings. The exact candidate commit passed the full Linux and macOS CI gates, includinggo test ./... -covermode=atomic, coverage enforcement, formatting, module tidiness, vet, vulnerability scan, deadcode, build, CLI smoke, release-script tests, and snapshot packaging: https://github.com/openclaw/gitcrawl/actions/runs/33362738281A separate live smart-HTTP test confirmed that current main cancels a stalled initial clone after 121.18 seconds but leaves a partial checkout that prevents retry. That existing clone-ownership/recovery issue is documented for a separate maintainer decision; this diagnostic-only change does not alter it.
macOS real-Git reproducer