Closed jcpitre closed 8 months ago
This contribution does not follow the conventions set by the Google Java style guide. Please run the following command line at the root of the project to fix formatting errors: ./gradlew goJF
.
✅ Rule acceptance tests passed. New Errors: 0 out of 1520 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%. Dropped Errors: 0 out of 1520 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%. New Warnings: 0 out of 1520 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%. Dropped Warnings: 0 out of 1520 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%. 0 out of 1520 sources (~0 %) are corrupted. Commit: 81c32f594ef30034a3d326da24b48dac9935db8d Download the full acceptance test report here (report will disappear after 90 days). ✅ Rule acceptance tests passed.
✅ Rule acceptance tests passed. New Errors: 0 out of 1520 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%. Dropped Errors: 0 out of 1520 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%. New Warnings: 0 out of 1520 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%. Dropped Warnings: 0 out of 1520 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%. 0 out of 1520 sources (~0 %) are corrupted. Commit: c8c30d1fd79eee406a60296930984583f5dfc7ec Download the full acceptance test report here (report will disappear after 90 days). ✅ Rule acceptance tests passed.
Summary:
Closes #1707
If there is no timeout on the version endpoint, this PR changes nothing. Changed the code so it does not generate an exception when the version endpoint is called but times out. Another problem was that the current version (obtained from the jar files) was discarded if there was a time out calling the version endpoint.
Expected behavior:
Web validator does not hang forever if there is a timeout while calling the version endpoint. If the timeout happens, the version is still correct in report.html
Testing tips
The timeout is intermittent, and probably only occurs when the validator service is brought up. To test this, you could add a delay in VersionResolver.java, e.g. Thread.sleep(5100) to simulate that the endpoint takes a long time to respond. The delay should be above 5000 ms, since it's the time used for the timeout.
Please make sure these boxes are checked before submitting your pull request - thanks!
gradle test
to make sure you didn't break anything