Thanks Mickael for the suggestion... really the UIExtensionTracker was a very late consequence of the generated p2 installer plan. It was multiple layers, events and threads away.
We were able to track it down to a custom touchpoint that depends on some org.eclipse.equinox.p2 bundles.
We were also able to replicate it with a minimal example touchpoint using Eclipse Java IDE 4.19.
In 4.19 the p2 bundles are transitively using org.bouncycastle.bcpg_1.65.0 and org.bouncycastle.bcprov_1.65.1.
In 4.21 they were upgraded to org.bouncycastle.bcpg_1.69.0 and org.bouncycastle.bcprov_1.69.0.
During the first phase of the update where the touchpoints are updated, p2 computes an installer plan which basically says that the 1.65 version is not used anymore (which in fact WILL be true after restart) and resolves that it needs to be replaced by the 1.69. The problem is that based on this plan it is transitioned to UNRESOLVED (dispatching an event that triggers other events (like RegistryChangeEvent) and ultimately listened by UIExtensionTracker) producing the errors. After a restart all works ok.
What is more odd is that after the installation finishes the jars of the 1.65 version are deleted (which if I'm not wrong it would prevent a rollback to the previous state after the installation)
For now, as a workaround we are making our touchpoint to explicitly depend on the version 1.65, but that leaves us shipping both versions and don't prevent that in a future upgrade it will happen again with another version.
Do you think it is a bug (I could report it) or something that we are doing wrong?
Thanks in advance
Martin
