It turns out DBUS method call in chrome must be asynchronous: https://chromium.googlesource.com/chromiumos/docs/+/master/dbus_in_chrome.md#Method-calls-must-be-asynchronous

Can we take the alternative approach and pass a callback to OnCustomInstall to proceed update?

Hi Xiaochu - Sorin and I have been discussing this and we'd like to first make changes to the architecture of the component updater so that failure to call such a callback doesn't DoS the entire update system.

I agree this change would be semantically nice, but does it practically stop any harmful races?

Thanks, Josh!

In our current design, update has priority over any other operations. All other operations (next update, uninstall) are buffered or canceled until current update is done. This is currently our model to handle race (?). But since we have to use non-blocking method call inside OnCustomInstall, this model isn't working exactly. Allowing callback in OnCustomInstall should bring this model integral again.

A particular harmful race is load (or uninstall) after install. Sometimes I could observe LoadComponent API fails in the first call due to the case where component is being loaded when component is not fully registered (in OnCustomInstall). This disappears when I make the dbus call (OnCustomInstall) blocking. I never observed race for uninstall after install, but theoretically it could happen like the 'load' case.

Since component is no longer copied and OnCustomInstall does nothing any more, we do not need to block it any more.