Summary
End-to-end tests occasionally fail due to timing: the test asserts before GitHub (or the local daemon) has caught up with a prior write. Failures have shown up in first-sync and pull scenarios (e.g. scenarios 9 and 11), but the underlying theme is fragile polling, not a single product bug.
Goal
Strengthen e2e wait conditions in general so tests don’t depend on implicit delays or a single fixed sleep. Prefer:
- Polling with a clear timeout and actionable failure message
- Waiting on observable state (file content, remote snapshot, CLI output) rather than time alone
- Shared helpers so new scenarios don’t reintroduce race-prone patterns
Out of scope (for this issue)
- Product changes to GitHub fetch semantics unless a test proves a real consistency bug after waits are fixed
Former context
Previously framed as GitHub fetch() read-after-write / ref=main inconsistency. May still exist, but this issue tracks test harness robustness first.
Summary
End-to-end tests occasionally fail due to timing: the test asserts before GitHub (or the local daemon) has caught up with a prior write. Failures have shown up in first-sync and pull scenarios (e.g. scenarios 9 and 11), but the underlying theme is fragile polling, not a single product bug.
Goal
Strengthen e2e wait conditions in general so tests don’t depend on implicit delays or a single fixed sleep. Prefer:
Out of scope (for this issue)
Former context
Previously framed as GitHub
fetch()read-after-write /ref=maininconsistency. May still exist, but this issue tracks test harness robustness first.