Intermittently Errno::ENOENT errors #98
Comments
|
Hi Brian! It looks like the Errno::ENOENT error you are getting is indicating a file does not exist even though you can see it in your directory. This also seems weird since on line 78 we check that the file exists: Do you think there is something in the background that is moving or renaming files? |
|
Yes it is super weird. I can't think of anything that would move or rename files, and we don't see anything like this anywhere else in our error monitoring. Any tips on how we could troubleshoot it? |
|
Hi @f1sherman! I want to check in and see if you're still experiencing this issue. Recently, one of the folks on our team made some improvements to this repo, and those changes may or may not impact this issue. We haven't been able to reproduce this issue, but we'll continue to keep an eye out for it. |
|
@ashleywillard thanks for the heads up! I haven't seen this crop up in at least 2 weeks. I'll try removing our code that swallows the error and report back here if it comes back. Thank you! |
|
@ashleywillard unfortunately this error came back after I removed our patch :(. |
|
Darn! We still have yet to see this error but I will let you know if we do. It seems like this issue might be tricky to reproduce on our end. |
|
I recently started experiencing this issue as well. It happened when I reorganized some of our internal gems within our mono-repo. We haven't had this problem at all previously. When it started, we had CodeOwnership on version Is there anything you might recommend to look into to help debug? |
Errno::ENOENT is occuring intermittently for some users. This can happen even when the file seems to exist at the time. Since we were already returning quietly if a file did not exist, just try to read the file and rescue exceptions, returning silently. Fixes #98
|
Hi @f1sherman and @timlkelly, Are you seeing these errors on CI builds? In containers? The list of reasons why we'd see an ENOENT for a file that does exist, but for different files each time, is a pretty small set of possible causes (race conditions, filesystem IO problems, etc). Are the files that are raising ones that you would expect to have annotations? We pushed #121 to solve this by rescuing for now since it's hard to diagnose exactly why this is happening. |
|
I have not seen it in CI, only in running Kubernetes pods in Production. |
|
Same, I have not seen this in CI. Only in production, also Kubernetes pods. Do you mean the File Annotation ownership? No, the files I've seen so far in the error reports are Package-based Ownership. |
Errno::ENOENT is occuring intermittently for some users. This can happen even when the file seems to exist at the time. Since we were already returning quietly if a file did not exist, just try to read the file and rescue exceptions, returning silently. Fixes #98
Errno::ENOENT is occuring intermittently for some users. This can happen even when the file seems to exist at the time. Since we were already returning quietly if a file did not exist, just try to read the file and rescue exceptions, returning silently. Fixes #98
We intermittently (a few times a week) see
Errno::ENOENTerrors when callingCodeOwnership.for_filewhere code ownership claims that a file we're looking up ownership for doesn't exist. It happens for different paths, not always the same path. There doesn't seem to be any obvious pattern for when this happens. The file exists and is found on 99.9% of requests. I've included the gem-specific portion of the trace below. Any ideas on how to track this down? For now we've added abegin/rescueblock around it, but obviously that's not an ideal solution. It's really weird given that I can pass a path that definitely doesn't exist toCodeOwnership.for_fileand it doesn't error, just returnsnil.The error has the signature
Errno::ENOENT: No such file or directory @ rb_sysopen - path/to/file/that/exists.rb.The text was updated successfully, but these errors were encountered: