Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Difference between lock.mtime and stat.mtime precision #82
Possibly related to #79
We are still getting a lot of reports about stale locks, often on CI platforms (and docker). One possible cause might be users who are using Node <v9. It appears that in Node v9 there can be a difference in precision about the
updateLock 2019-03-23T09:30:18.519Z 2019-03-23T09:30:18.519Z 10:30:33 precision ms 10:30:33 createdMtimeChecked 1553333418519 1553333418519 10:30:33 mtime set to 2019-03-23T09:30:33.523Z 10:30:33 updateLock 2019-03-23T09:30:33.523Z 2019-03-23T09:30:33.000Z 10:30:48 precision ms 10:30:48 createdMtimeChecked 1553333433523 1553333433000
(lines above are: <function.name> <lock.mtime> <stat.mtime>)
After the last line the lock gets compromised due to the 523ms difference
-- edit --
@satazor Its not really unnecessary when it squashes buggy behaviour I guess (and there is no other workaround)
I spent a fair amount of time trying to debug this but am afraid although I can reproduce it consistently in one of my Nuxt projects I still dont understand what causes it. Could be linux/fs behaviour, could be node. Could be related to high cpu usage or high io usage. Sorry to say I havent been able to put my finger on it yet. Any suggestions what I could do to get to the bottom of this would really be appreciated though :)
@pimlie what I’m saying is that there’s an alternative solution that we discussed in another PR that would solve this issue while not doing any additional io syscall.
You may read the suggestion in the link I gave above but @alanshaw has more context.
Anyway, I will also accept a PR that does the extra syscall to resolve the bug.
Thanks for the quick work. Can confirm the fix seems to work:
I also checked whether I still get a warning when I manually change the mtime once the lock has been created and that works too: