finos / finos/architecture-as-code
calm-hub: GitHub clone lifecycle has no coordination with concurrent readers
- Dominant language
- TypeScript
- Stars
- 399
- Forks
- 138
- Avg merge
- 2d 14h
- Merged PRs (30d)
- 37
Description
Nothing coordinates the clone directory / registry against concurrent readers, at two points in the lifecycle.
1. **No readiness gate during the initial clone.** `GitHubStartupInitializer.onStart` kicks off the clone asynchronously and returns immediately — Quarkus finishes starting before it completes. `InMemoryRegistryService` starts empty, so a request during the clone window hits `verifyNamespace` against an empty list and gets 404 rather than 503. Class javadoc has been corrected (previously claimed a `@Readiness` endpoint that doesn't exist) and now points callers at `GitHubCloneManager.getState()`, but no gate exists.
A narrower ordering gap in the same area: `GitHubCloneManager.cloneAll()` sets `state = READY` on its last line, but `registryService.rebuild(...)` — the step that actually populates the registry — runs after `cloneAll()` returns. A gate on `getState() == READY` alone has the same hole: state can read READY while the registry is still empty.
2. **`reset --hard` races with concurrent reads during periodic resync.** `GitHubCloneManager.pullAll()` → `GitHubRepoSync.pullRepo` does `fetch` + `reset --hard` directly against the live clone directory, with no coordination against a request thread mid-`GitHubFileReader.readContained` on the same directory — can serve a torn/partial file, or a `NoSuchFileException`.
**Fix**: for 1, a filter ahead of `verifyNamespace` returning 503 while `cloneManager.getState()` is `INITIALIZING`/`CLONING`, gated on the registry actually containing the expected namespaces (not clone state alone). For 2, read/write coordination per namespace — clone into a fresh directory and atomically swap a pointer, or a read-write lock around `GitHubFileReader` reads. Same underlying gap; fix together.
(jpgough-ms review thread on GitHubStartupInitializer.java:68, #3066; item 2 found while building the DOMAIN_READ integration test.)
Contributor guide
Research direction
Start with GitHubStartupInitializer.onStart, GitHubCloneManager.cloneAll()/pullAll(), InMemoryRegistryService.rebuild, GitHubRepoSync.pullRepo, and GitHubFileReader.readContained. Run the DOMAIN_READ integration test to reproduce the lifecycle and resync windows. Done means initialization returns 503 until the registry is populated and concurrent reads cannot observe torn clone contents.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github, java
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 48/100