While I was working on Bug 1648188, the Search Service initialization outcome is confusing to understand.

We have a get isInitialized() method which does not tell us if the Search Service has successfully initialized. If Search Service has successfully initialized then callers can call use Search Service's interface without failure. isInitialized() returned true when the Search Service has finished its attempt at initialization and has an outcome - whether that attempt is a success outcome or failure outcome. isInitialized() doesn't say that the Search Service has properly initialized and is ready to be used.

There are some external callers that are waiting for the Search Service's initialization outcome. These callers do not want to trigger Search Service init, but just wants to know if it's already trying to init.

While brainstorm ways to make isInitialized() clearer, we can have a few different methods.

• hasSuccesfullyInitialized is created in my patch for Bug 1648188.

Some other functions to consider implementing are:

• hasInitializationFailed
• waitForInitializationOutcome
• get rid of isInitialized()

When we refactor this, we have to change all external calls to isInitialized. Some of these callers are waiting for an outcome, while others want to know if Search Service has succeeded. More investigation is required to see if this refactor idea will work.

We should also create an "init-failed" notification.
Currently, the system extension expects "init-complete" but there's a possibility that the Search Service has failed, and when it does fail, we are still sending a "init-complete" notification.

This is unclear because Search Service finished its attempt at initialization but that doesn't mean its complete. It could mean it finished trying to initialize but failed to initialized. The extension system doesn't handle when Search Service fails, it's always expecting success. Perhaps, we need another path in the code for "init-failed" notification in extension system.