I think saying "use sync instead" @internal/syncer/syncer.go:879-882 is a bit misleading. Not all the errors could be fixed with sync. Thoughts? · Entire

Discussion on Sync Usage

I think saying "use sync instead" in @internal/syncer/syncer.go:879-882 is a bit misleading. Not all the errors could be fixed with sync. Thoughts?

Agreed Points

Agreed. At line 876, the "use sync instead" hint is accurate — CanReplicateRelay returns a structural reason ("target lacks relay capability"), and switching to sync mode is the actual fix.

But line 881 wraps executeReplicate, which can fail for any number of unrelated reasons: network errors, push rejections, source-side fetch failures, pack assembly issues, context cancellation. None of those become "use sync" problems — sync would hit the same network/auth/push issues. Worse, the hint sends users down a wrong-shaped path when the real problem is transient or environmental.

Suggested Changes

I'd drop the suffix from 881 and let the wrapped error speak for itself:

return result, fmt.Errorf("replicate relay failed: %w", err)

Keep 876 as-is since that diagnosis is genuinely actionable.

Want me to make the change?

yes please

Final Updates

That test targets the --force rejection path (line 564), not the executeReplicate wrap — it's unaffected.

Done. Dropped ; use sync instead from the executeReplicate failure wrap; the two structural cases (lines 564, 810, 876) keep the hint since switching to sync genuinely is the fix there.

Commit Information

Make replicate error message less confusing
Entire-Checkpoint: 46c64a68d58f+1/-1