fix: getFeatures() invocation in plugin start() unhandled error

[panaaj]

(Addresses #1777)
Add test to getFeatures() to check if pluginManager has been initalised prior to interrogating features.

Invoking getFeatures() in a plugin start() function causes an error as the pluginManager is still initialising plugins.

Added a test prior to features being interrogated and throw a meaningful error on exception.

[tkurki]

I think the proper fix would be to change getFeatures return type to a Promise. Not really fond of the caller receiving an ambiguous failure, forcing a retry strategy.

This however may create a kind of a deadlock: getFeatures never returns because all plugins do not finish starting up because they are waiting for getFeatures...

[panaaj]

Implemented a "wait a max number of retries" approach.
Will not throw but rather return an empty array for plugins in return value if maxRetries is reached.

[panaaj]

@tkurki any further feedback?

[tkurki]

I think I was a bit too hasty with my Promise suggestion. I think using PropertyValues would be a much more sane API, as the listeners (other plugins) would be forced to handle updates in the set of features available not only during startup but all the time. For example when another plugin is activated.

What do you think?

[tkurki]

See my comment about PropertyValues.

[panaaj]

Seems a reasonable approach to me.
So if I understand correctly:

1. We don't need to expose getFeatures() to plugins at all....it will only need to service the API endpoint.
2. Plugins will advertise the features they provide using PropertyValues
3. API's implemented on the server will also advertise using PropertyValues process.

[tkurki]

That's correct. So next steps would be

• deprecate the current getFeatures: log an error message, remove from the documentation
• document the PropertyValues mechanism
• alter APIs in the server to use PropertyValues
• close this PR...