The README in pkg/apis/work/v1/ shows a NewWorkApplierWithRuntimeClient example using a controller-runtime client.Client, but it's only documentation, not an exported function.
Users can't implement it externally because all WorkApplier fields are unexported.
This matters because controllers that watch ManifestWorks via controller-runtime and read from a separate work informer factory lister hit a dual-cache race.
The controller-runtime watch fires before the work informer syncs, causing safeToSkipApply to read stale generation and skip a needed patch.
Using a single controller-runtime client for both the watch and the lister eliminates this race.
Proposal: Export the NewWorkApplierWithRuntimeClient constructor as shown in the README.
The implementation is already documented, it just needs to be actual code.
Ref: stolostron/multicluster-mesh-addon#109
The README in
pkg/apis/work/v1/shows aNewWorkApplierWithRuntimeClientexample using a controller-runtimeclient.Client, but it's only documentation, not an exported function.Users can't implement it externally because all
WorkApplierfields are unexported.This matters because controllers that watch ManifestWorks via controller-runtime and read from a separate work informer factory lister hit a dual-cache race.
The controller-runtime watch fires before the work informer syncs, causing
safeToSkipApplyto read stale generation and skip a needed patch.Using a single controller-runtime client for both the watch and the lister eliminates this race.
Proposal: Export the
NewWorkApplierWithRuntimeClientconstructor as shown in the README.The implementation is already documented, it just needs to be actual code.
Ref: stolostron/multicluster-mesh-addon#109