I think this is quite an important issue. If pluginsync has issues you really can't know what versions of providers/facts/etc are used to apply your catalog and quite bad things can happen.
Ideally I'd say pluginsync failures should just prevent the catalog from being applied all together with some indication in last_run_summary.yaml and reports that this happened. If not the default behaviour then a setting to cause this to happen would be really good.
If the master doesn't have at least one module/lib directory, pluginsync will fail (and I think the same is true for facts.d for pluginfactsync) due to PUP-2608. So that needs to be fixed before this ticket can be.
Previously, if a puppet agent failed to pluginsync, it would continue trying to request a catalog and apply it with the possibly incorrect fact and plugin versions, leading to obscure errors or worse, data corruption. The puppet agent will now abort the run if pluginsync fails.
Previously, if a puppet agent failed to pluginsync, it would continue trying to request a catalog and apply it with the possibly incorrect fact and plugin versions, leading to obscure errors or worse, data corruption. The puppet This release adds a new setting `ignore_plugin_errors` which defaults to true preserving the existing behavior. If set to false, then the agent will now abort the run if pluginsync fails.
Previously, if puppet agent failed to agents ignored pluginsync, it would continue trying to request a catalog errors and would apply it with the catalog with possibly incorrect fact facts and plugin versions, leading to obscure errors or worse, data corruption. This release adds a new setting `ignore_plugin_errors` which defaults to true preserving the existing behavior. If set to false, then the agent will abort the run if pluginsync fails. The setting defaults to true so the old behavior is preserved. In Puppet 7, the default value will be switched to false.