Test failure for 0.12.0 on Arch Linux #1047
Comments
|
Weird! I tried it locally inside a Docker container, and it worked for me. 🤔 Logs
|
|
on Arch Linux, running running |
|
That looks like a flaky test to me as the code that the command runs is the same for this test. Can you run that single test a few times to see how often it fails? The initial issue might also be caused by a flaky test. @orhun, can you also run the failing cache test a few more times to see if it's flaky? |
|
Unfortunately I'm running things inside a chroot environment via PKGBUILDIs there a way to specify which tests to run or skip tests when edit: I also get the same failure when I First 5 runs: 6th run: 7th run: all passed. It's weird :/ |
|
@orhun, can you run the following command manually? rm .lycheecache
echo "slack://user\nhttps://example.com/" | lychee --cache --verbose --no-progress --exclude https://example.com -The output should look exactly like this: echo "slack://user\nhttps://example.com/" | lychee --cache --verbose --no-progress --exclude https://example.com -
? [EXCLUDED] https://example.com/ | Excluded
? [IGNORED] slack://user | Unsupported: Error creating request client: builder error for url (slack://user): URL scheme is not allowed
🔍 2 Total ✅ 0 OK 🚫 0 Errors 💤 1 ExcludedAnd |
|
Here is the output: And |
|
could that be caused by parallelism? this test requires the cache file to be empty, but could the cache file be generated by other unit test? |
|
I was suspecting that as well. I tried the following: And it all passed this time! I have 2 questions:
Thanks @lebensterben for on-point deduction. |
|
This is actually a bug. If a user spawns multiple instances of lychee and has all of them using a cache file, then there could be a "race condition", if different instances of lychee interpret the same cached result differently. I propose that, before writing results to the cache file, lychee should "lock" it somehow. |
|
Couple of action items:
|
Yes, that would be great!
FWIW a quick search points out to the following crates: Also, we can look into what |
|
if different lychee instances interpret the same cached result differently, it's problematic. Currently, the status is represented by one of success status code, failure status code, filtered out by exclusion rules, or unsupported scheme. In fact we should not differentiate success status code from failure status code, and we only need to store status code without labeling them separately. We should leave to each lychee instance to determine whether a status code is a success. another source of confusion may arise from different network settings when lychee is running. In particular, user agent and proxy are likely to affect the result. Therefore we should also store these "metadata" in cache, and be cautious when using cached result where network settings also changed. If we do our best to avoid the aforementioned problem, then for practicality we should not worry about race condition. As for the failed test, I still think we should use cargo-next-test for its parallelization. But let's use a different cache file name for the failed test. |
|
FYI I released |
Hello!
I got this error while packaging
lychee0.12.0for Arch Linux:Logs
I'm simply running
make test. Is there anything else I need to do?The text was updated successfully, but these errors were encountered: