Repository navigation
fix(restheart-mongo): flow.sh waits for RESTHeart to answer, not for a deadline - #154
Draft
slayerjain wants to merge 3 commits into
Draft
slayerjain wants to merge 3 commits into
slayerjain wants to merge 3 commits into
Conversation
…a deadline record-traffic gave RESTHeart a fixed 60 s, by a `date +%s` deadline, and then slept another 5 s. Bootstrap gave it a caller's count of seconds (240). On a loaded CI host a JVM can take longer than any such count to start: keploy/enterprise's restheart lane recorded nothing when RESTHeart answered after the 60 s, on #2922 (pipeline 11773), with keploy's eBPF load held up by the host. restheart_wait_for_app now waits for RESTHeart to answer its root (200, or 401 asking for credentials) for as long as its container is running. A container that has exited, or is not there, ends the wait at once and fails it, with the container's last log lines. One that runs and never answers is left to the caller's own bound (a CI step's timeout). The 5 s sleep is gone: the app is up once it answers, since its compose starts it only after Mongo is healthy. bootstrap still accepts a seconds argument from callers that pass one (keploy/enterprise's lane passes 240) and ignores it. run-and-measure.sh's 120 x 2 s poll goes too: it now relies on flow.sh bootstrap's wait. The README examples drop the 240. Signed-off-by: slayerjain <shubhamkjain@outlook.com>
restheart-mongo sample coverage
Threshold: PR may not drop coverage by more than 1.0pp. Override per-repo via the |
… docker hiccup, as the verdict Review of 6870873: - A container that is created or restarting is on its way to running, so the wait keeps going for it. Only one that has exited, died, or is not there ends the wait. - A `docker inspect` that fails for another reason (a daemon slow under load) is not read as the container being gone. The wait goes on. - run-and-measure.sh's error now says that bootstrap failed, which can be RESTHeart not coming up or the seeding failing, not only the first. Signed-off-by: slayerjain <shubhamkjain@outlook.com>
…once when it does not answer Review of 4a65d8e: every docker error other than "No such" was taken as transient, silently and for ever, including exit 126/127 (no docker to run) and a socket it may not open. 126/127 now fail the wait at once, with what docker said; any other error is said once, and the wait goes on. Signed-off-by: slayerjain <shubhamkjain@outlook.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
restheart-mongo/flow.shnow waits for RESTHeart to answer, not for a deadline:record-trafficused to give RESTHeart a fixed 60 s (adate +%sdeadline), then slept 5 s more.bootstrapused to wait for a caller's count of seconds (240).restheart_wait_for_appnow waits until RESTHeart answers its root with 200, or with 401 (asking for credentials), for as long as its container runs:The 5 s sleep is gone. RESTHeart's compose service starts only once Mongo is healthy, so once RESTHeart answers, it is up.
Also:
bootstrapstill accepts the seconds argument older callers pass (keploy/enterprise's lane passes 240) and ignores it..github/workflows/scripts/run-and-measure.shdrops its 120 × 2 s poll and relies onflow.sh bootstrap's wait.240.Why
On a loaded CI host, a JVM can take longer than any fixed count to start. keploy/enterprise's restheart lane recorded nothing when RESTHeart answered after flow.sh's 60 s were up, because the host was holding up keploy's eBPF load.
The enterprise lane now waits for RESTHeart itself before it calls
record-traffic(await_ready), soflow.shfinds it answering at the first probe. Its own wait no longer cuts a slow start short.Testing
restheart-mongo: 307 tests recorded per cell, and every replay PASSED.restheart-mongoworkflow runs the standalonerun-and-measure.shpath.