You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The same result should be produced independently of the order of input items.
If I recall correctly, it already sorts its output before returning it.
I took a look just now and noticed that the failure here seems to originate in the rename tracker, It didn't find the matching pairs.
The answer here must be that it's a problem with the order in which the entries are made known to the rename tracker, which depends on timing. A dirwalk is used in one thread to detect untracked files, whereas another thread traverses the index to find missing and changed files.
It appears that the pair-matching algorithm is to not order-independent as it would expected to be - clearly a bug in the implementation.
I think it would be possible to reproduce this with a test that runs a similar set of files through significant permutations and runs rename tracking on it.
Originally posted by EliahKagan February 5, 2025
The i386 (32-bit x86) test-32bit job was not changed in #1830, which only changed the arm32v7 (32-bit ARM) job. But after CI passed there, the i386 job failed in the merge commit on the main branch. Although I would guess the failure might go away if the job is rerun, since it passed when it ran on the main branch of my fork when I fast-forwarded (synchronized) it, I don't know how a failure like this would plausibly happen even with low probability in the absence of a bug in gitoxide or its test suite:
That is the only failure in that job, and there are no failures in any of the other jobs, including of that test case. This is also not related to the ongoing ARM problems we've had on CI, because that is a 32-bit x86 job.
What might have caused that, and is it something we should worry about?
The text was updated successfully, but these errors were encountered:
The same result should be produced independently of the order of input items.
If I recall correctly, it already sorts its output before returning it.
I took a look just now and noticed that the failure here seems to originate in the rename tracker, It didn't find the matching pairs.
The answer here must be that it's a problem with the order in which the entries are made known to the rename tracker, which depends on timing. A dirwalk is used in one thread to detect untracked files, whereas another thread traverses the index to find missing and changed files.
It appears that the pair-matching algorithm is to not order-independent as it would expected to be - clearly a bug in the implementation.
I think it would be possible to reproduce this with a test that runs a similar set of files through significant permutations and runs rename tracking on it.
Discussed in #1831
Originally posted by EliahKagan February 5, 2025
The i386 (32-bit x86) test-32bit job was not changed in #1830, which only changed the arm32v7 (32-bit ARM) job. But after CI passed there, the i386 job failed in the merge commit on the main branch. Although I would guess the failure might go away if the job is rerun, since it passed when it ran on the main branch of my fork when I fast-forwarded (synchronized) it, I don't know how a failure like this would plausibly happen even with low probability in the absence of a bug in gitoxide or its test suite:
Here's a colorized rendering of the diff shown in the above test failure output.
That is the only failure in that job, and there are no failures in any of the other jobs, including of that test case. This is also not related to the ongoing ARM problems we've had on CI, because that is a 32-bit x86 job.
What might have caused that, and is it something we should worry about?
The text was updated successfully, but these errors were encountered: