phase a/fix graph health#46
Conversation
aksOps
commented
Apr 17, 2026
- chore(baseline): scaffold baseline dirs and gitignore
- chore(baseline): add seed-repo fetch script with pinned commits
- chore(baseline): add Maven verify + JaCoCo capture script
- chore(baseline): add flaky-test scan (N repeated runs)
- chore(baseline): add SpotBugs baseline capture
- chore(baseline): add dependency-tree + license snapshot capture
- chore(baseline): add frontend audit (npm audit + Vite + Playwright)
- chore(baseline): add index/enrich/serve-smoke pipeline capture
- chore(baseline): run pipeline on realworld-express
- chore(baseline): add OWASP dependency-check baseline capture (NVD sync needs retry)
- chore(baseline): add consolidator and publish first BASELINE.md
- fix(baseline): probe /api/stats for serve-smoke readiness instead of /actuator/health
- fix(serve): publish availability events so /actuator/health returns 200
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 15 minutes and 28 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Problem: /actuator/health on a running `code-iq serve` returned HTTP 503
with body {"groups":["liveness","readiness"],"status":"OUT_OF_SERVICE"},
even after the graph was fully loaded and /api/stats was returning real
data. This made the health endpoint unusable for K8s/Compose readiness
probes and confused baseline smoke-tests.
Root cause: ServeCommand.call() blocks on Thread.currentThread().join()
inside Spring Boot's CommandLineRunner.run(). Because the runner never
returns, Spring's ApplicationReadyEvent is never published, and neither
is the default AvailabilityChangeEvent that normally transitions
ReadinessState from REFUSING_TRAFFIC to ACCEPTING_TRAFFIC. With the
serving profile's probes enabled, the aggregated health endpoint stays
pinned at OUT_OF_SERVICE forever.
Fix: ServeCommand now explicitly publishes the two availability events
via a new markReady() method before blocking:
AvailabilityChangeEvent.publish(events, this, LivenessState.CORRECT);
AvailabilityChangeEvent.publish(events, this, ReadinessState.ACCEPTING_TRAFFIC);
markReady() is extracted for testability. A new ServeCommandTest case
verifies both events are published in the documented order.
Verified end-to-end against both seed repos via the updated pipeline
script: /actuator/health now returns HTTP 200 with status "UP".
| seed | ready | health_http | before |
|---------------------|-------:|------------:|-------:|
| spring-petclinic | 13s | 200 | 503 |
| realworld-express | 14s | 200 | 503 |
Follow-up (out of scope): GraphBootstrapper's
@eventlistener(ApplicationReadyEvent.class) is effectively dead code
for the same reason — the listener never fires because the event never
fires. Only not-a-bug today because enrich always runs before serve in
our pipeline, so the bootstrap fallback never actually needs to trigger.
c626f25 to
b73267c
Compare
|

