This message was deleted.
# general
s
This message was deleted.
g
Haven’t seen that. Are you on a different node version than Chris perhaps?
l
We have not seen that issue. And it's definitely not good. Does it survive a reboot? does it happen on every run (presumably with a different
pulumi#####
pipe)?
s
I believe we have checked all versions, but I will double check that one
I can reboot adn it still happens, didn't track the pipe number, lmme see....
l
also, do you potentially run any sort of antivirus or other disk-scanning tool?
Note: one thing you can do to workaround the issue while we investigate this is the following:
s
YES to the antivirus/diskcheck
l
1. it looks like you're makin a call to getSubnet. Are you making that call directly yourself?
s
Confirmed. The pipenames are different
l
i.e. right here: index.ts2630. That's what the callstack seems to indicate, but i just want to check before assuming
s
yes, lines 31 thru 36 are const subnet = azure.network.getSubnet({ name: config.require('subnet'), virtualNetworkName: config.require('vnet'), resourceGroupName: config.require('vnet-rg'), });
l
how do you then use that 'const subnet' later in your program?
s
I dont'. It's leftover code.
I can comment it out
l
well, that could certainly potentially help 😄
s
this is a working stack I use to try different things
l
in general though, until we figure out why you're gettin the EBUSY, what we can do is switch away from "synchronous invokes", and move to "async invokes". This will mean that instead of calling just
azure.network.getSubnet({ ... })
we would isntead call
azure.network.getSubnet({...}, { async: true })
.
However, if you do this, you'll get a Promise back.
So you'd either need to do:
await azure.network.getSubnet({...}, { async: true })
s
error: Running program 'C:\work\repos\hondofoozle' failed with an unhandled exception: Error: EBUSY: resource busy or locked, open '\\.\pipe\pulumi4203104520\invoke_req' at Object.openSync (fs.js4483) at Object.tryGetSyncInvokes (C:\work\repos\hondofoozle\node_modules\@pulumi\pulumi\runtime\settings.js16329) at invokeSync (C:\work\repos\hondofoozle\node_modules\@pulumi\pulumi\runtime\invoke.js9536) at Object.invoke (C:\work\repos\hondofoozle\node_modules\@pulumi\pulumi\runtime\invoke.js8424) at Object.getClientConfig (C:\work\repos\hondofoozle\node_modules\@pulumi\core\getClientConfig.ts3168) at Object.<anonymous> (C\work\repos\hondofoozle\index.ts59:28) at Module._compile (internal/modules/cjs/loader.js93630) at Module.m._compile (C\work\repos\hondofoozle\node modules\ts node\src\index.ts439:23) at Module._extensions..js (internal/modules/cjs/loader.js94710) at Object.require.extensions.<computed> [as .ts] (C\work\repos\hondofoozle\node modules\ts node\src\index.ts44
l
Or you'd need to do:
pulumi.output(azure.network.getSubnet({...}, { async: true });
these code changes will sidestep the issue above completely.
s
ok
l
my guess though is that this might be related to antivirus. it might be seeing us open a connectoin between our processes and it might be scanning it.
that's a guess on my part though.
Note: this general space is one we know we have some issue around. We have an issue tracking resolving it all entirely in the near term.
s
ok
l
LMK if you need any more info or help here.
s
so run these failed commands azynchronously?
for now?
l
if you do need them, yes.
s
k, will try.
thanks for the rapid response
l
if antivirus is the cause, let us know.
we may have to code ourselves up to be a little more resilient to this possibility