I just had a short internet outage which was exactly the time I tried to Local Flash from the workbench. When this is the case and the device was trying to connect to the Particle Cloud (flashing cyan) then it is not possible to put the device into DFU mode via the USB and it returns an error - although it then goes on to successfully update the device!
The reason is (most likely) that the device is not attending to USB communication while blocking for WiFi/Cell/Mesh reconnect and Workbench has a timeout for retrying.
If the command was queued successfully tho’ the device may still - though delayed - do what the command request instructed it to without Workbench knowing of it.
However, since WB doesn’t care whether it was able to put the device into DFU Mode it will still attempt to flash via USB since it could well be that the user has put the device in DFU Mode while the build was running.
It definitely waits and then puts the error message out but since it has got the device in DFU mode this seems a redundant error message? It was really aimed at @m_m
How long does it wait?
I have seen the behaviour you described but the time between sending the command for the first time and the error message being printed was a few seconds but the time for the device to actually turn into DFU Mode was even longer.
Hence the assertion that the WB timeout was shorter than the device was blocking.
If the time difference between the two instances is quite short it may be perceived as a redundant message but WB has no way of telling whether the device will eventually get into DFU Mode without hanging round “forever” so some timeout limit has to be set and expiration of that should be reported.
BTW, I also had instances where the application code was “blocking” control request treatment and having WB indicate the fact did allow me to manually engage DFU Mode before the build had finished.
However, having @m_m chime in on this should calrify things for both of us 
I have also has same experience - more so since 1.4.4
I am using 1.4.4 as well - and I agree with all your observations @ScruffR. Need to wait and see what the response is!
we are aware of the awkwardness around status messaging in the log.
the underlying particle usb dfu command can fail for all sorts of reasons - most commonly due to the device itself being busy and slow to change modes. best bet is to manually place the device into DFU mode (docs).
if you notice this issue occurring often, take a look at your firmware’s setup() and loop() fns to ensure you aren’t doing things that might block or otherwise impede the responsiveness of the device. try running particle usb dfu <device> outside of the flash routine and note if / when responsiveness improves.
2 Likes