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
fastly version (base) (story/CORE-734*) 14:01:01
fastly fastly version (base) (story/CORE-734*) 14:01:01
Fastly CLI version v10.15.0 (0a1665b)
Built with go version go1.22.7 linux/amd64 (2024-10-30)
Viceroy version: viceroy 0.12.1
What happened
Happens:
While running fastly compute serve --watch we ended up with an infinite loop of rebuilding, it seemed that something on the specific Mac, that was used, was doing a chmod operation as soon as fastly compute serve was issued creating an endless loop.
I debugged the fastly cli code and saw that it was always the fsnotify operation CHMOD.
Digging deeper into the code and into fsnotify it's stated in their documentation that taking action on Chmod isn't recommended.
See their code base: https://github.com/fsnotify/fsnotify/blob/2d133b81be1e26628491698a699ef9ce9fb71ed9/fsnotify.go#L135
Our theory is that company "must have" software (anti-virus) is getting triggered by the fastly compute serve operation
and that starts this loop.
Expecting:
Rebuild shouldn't occur if I haven't actually changed the files (write, create, remove, rename)
Temporary solution:
I patched the code by adding a if statement to only allow the event handler if the event had either Create, Remove, Rename, Write, which would exclude if it was only a Chmod operation.
I'm not sure if that's a good solution in the long run, maybe an cli option to control the behaviour of watch would be better
The text was updated successfully, but these errors were encountered:
Thanks for the excellent report! I agree with your findings and conclusion; the permission bits (mode) of the file are not relevant for triggering a rebuild, and it makes sense to only pay attention to the other modifications. Based on the comment in that link there are some non-mode changes which can also send a CHMOD event, but I don't see them as being a big concern (one is removal of a hard-link, and the other is truncation of a file).
If you want to submit a PR with your suggested changes to this logic, it would be very welcome.
Version
fastly version (base) (story/CORE-734*) 14:01:01
fastly fastly version (base) (story/CORE-734*) 14:01:01
Fastly CLI version v10.15.0 (0a1665b)
Built with go version go1.22.7 linux/amd64 (2024-10-30)
Viceroy version: viceroy 0.12.1
What happened
Happens:
While running
fastly compute serve --watch
we ended up with an infinite loop of rebuilding, it seemed that something on the specific Mac, that was used, was doing a chmod operation as soon asfastly compute serve
was issued creating an endless loop.I debugged the fastly cli code and saw that it was always the fsnotify operation
CHMOD
.Digging deeper into the code and into fsnotify it's stated in their documentation that taking action on Chmod isn't recommended.
See their code base: https://github.com/fsnotify/fsnotify/blob/2d133b81be1e26628491698a699ef9ce9fb71ed9/fsnotify.go#L135
Our theory is that company "must have" software (anti-virus) is getting triggered by the
fastly compute serve
operationand that starts this loop.
Expecting:
Rebuild shouldn't occur if I haven't actually changed the files (write, create, remove, rename)
Temporary solution:
I patched the code by adding a if statement to only allow the event handler if the event had either
Create
,Remove
,Rename
,Write
, which would exclude if it was only aChmod
operation.I'm not sure if that's a good solution in the long run, maybe an cli option to control the behaviour of watch would be better
The text was updated successfully, but these errors were encountered: