Open dimo414 opened 1 year ago
cc @akshaysngupta
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.
I have yet to see stalebot provide any utility to a single project it is used on. I don't mind that y'all aren't actively acting on this bug but it's a really poor experience to treat such bugs as "stale" and have a bot auto-close them. The message it sends is the project would rather close bugs than act on them.
Hey @dimo414 ,
Sorry for the delay. Windows is mostly supported by folks at microsoft such as @akshaysngupta as most other maintainers, etc. don't have / work on windows.
Thanks @KBaichoo, like I said no worries your timing to resolve this specific issue, I've worked around it in the meantime. But stalebot is really bad, would love if y'all could get rid of it.
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.
Go away stalebot.
Description:
I am using xDS configs via the filesystem on Windows and observed that my config files were not being picked up, despite the same behavior working correctly on Linux. I believe I have narrowed it down to an issue with how filesystem events on Windows are being monitored, because I was able to trigger config refreshes manually even though my application logic wasn't working.
My existing code (which works on Linux) looks like so:
The fix is:
That is to say, on Windows filesystem updates are only considered valid if the source file is in the same directory as the watched destination file.
To me this seems like a bug in the Windows file watching implementation, but if this is considered WAI this limitation should be clearly documented - none of the documentation I've looked at mentions any constraints about where the replacement file comes from.
Repro steps:
debug
logging forconfig
andfile
(this isn't needed but makes the issue easier to observe)os.replace()
or another atomic filesystem operation move the prepared change into placeConfig:
(sharing relevant parts from the
/config_dump
endpoint)Logs:
I started Envoy with
--component-log-level=config:trace,file:trace,init:debug,http:debug,router:debug,admin:debug
and have included below theinit
,config
,file
, andupstream
logs.Notice in particular the
notification: handle: ... action: 1
and2
lines; these correspond to this logging statement and the numbers referenceFILE_ACTION_*
constants, where 1 and 2 are added and removed, respectively. These events were triggered byos.replace()
calls in our application, but do not result in a config refresh in Envoy. Further down there is a pair ofaction: 4
andaction: 5
events (file renamed from and to, respectively) that do trigger a config refresh. This was caused by me manually copying the config file within the current directory and then overwriting it viaos.replace()
in the terminal. The only difference between the automated overwrites and my manual one is the location of the source file.