No cleanup when an instance becomes the singleton node: the cleanup belongs to the startup of the member whose extensions changed. A member that becomes the singleton node later (for example while the preferred member restarts) did not change its extensions and might not know all the extensions installed through the previous singleton node, so it must not delete their entries. The cleanup now runs only when the singleton node starts.
The indexing catch-up of a member that becomes the singleton node after its startup is delayed by the new extension.index.indexOnSingletonGainDelay property (in seconds, 300 by default), and runs only if the member is still the singleton node when the delay expires, so a short restart of the preferred member does not trigger a crawl on another member. The security scanner of the new singleton node starts once that indexing finishes.
In the shared index case, the singleton node indexes all the wikis of the farm: the list of wikis is read again before each scheduled indexing (created wikis are added, deleted wikis are forgotten), inside an execution context. This costs more than the indexing of only the wikis loaded on the member (each run validates the indexed extensions on every wiki namespace), but it is done by a single member instead of every member.
Clusters where each member has its own embedded Solr (and so its own extension index) also had the duplicate "new security vulnerabilities" notifications: each member scans its own index and counted the same vulnerabilities as new. The notification is now sent only by the cluster singleton node when remote observation is enabled; each member keeps scanning its own index. Without cluster nothing changes.
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
