kubernetes/controller/cmd/main.go (1)

113-114: Default preserves prior drop behavior — document the tuning signal.

Default 10 matches the previously hardcoded buffer, so out-of-the-box behavior (and the original conformance flakiness scenario) is unchanged unless operators explicitly raise this flag. Since the earlier RequeueAfter safety-net was dropped, dropped events no longer have a timer-based recovery path; the only signal operators have is EventChannelDropsTotal.

Consider calling out the resolver_event_channel_drops_total metric in the flag help text so operators know when/why to increase the value.

-	flag.IntVar(&resolverSubscriberBuffer, "resolver-subscriber-buffer-size", 10, //nolint:mnd // no magic number
-		"The buffer size for each subscriber's event channel. A larger buffer reduces the probability of dropped resolution events under load.")
+	flag.IntVar(&resolverSubscriberBuffer, "resolver-subscriber-buffer-size", 10, //nolint:mnd // no magic number
+		"The buffer size for each subscriber's event channel. A larger buffer reduces the probability of dropped resolution events under load. "+
+			"Tune upward if the resolver_event_channel_drops_total metric is non-zero.")

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@kubernetes/controller/cmd/main.go` around lines 113 - 114, The flag help for
resolverSubscriberBuffer (set via flag.IntVar with name
"resolver-subscriber-buffer-size") should be updated to mention the tuning
signal metric so operators know when to increase it: modify the flag's help
string to reference the Prometheus metric resolver_event_channel_drops_total (or
resolver_event_channel_drops_total) and explain that if that metric increases
under load they should raise the buffer size to reduce dropped resolution
events; keep the default value but document that raising the flag mitigates
drops now that the RequeueAfter safety-net was removed.

kubernetes/controller/internal/resolution/workerpool/workerpool.go (1)

98-100: LGTM — configurable buffer is implemented correctly.

PoolOptions.SubscriberBufferSize, the <= 0 defaulting to 10, and the use of wp.SubscriberBufferSize in Subscribe() are consistent and preserve backward-compatible behavior.

One residual concern worth flagging (not a blocker): the non-blocking broadcast in handleWorkItem (Lines 369–387) silently drops events when a channel is full. All three controllers (resource, deployer, component) return immediately on ErrResolutionInProgress with no RequeueAfter fallback—they rely purely on event-driven re-triggering. Under sustained bursts, if a drop happens, this leaves a path to a permanently-stalled Ready=False / ResolutionInProgress object with no timeout recovery. Consider either:

• keeping the 30s RequeueAfter safety net on the ResolutionInProgress return paths as defense-in-depth, or
• making the broadcast blocking with a short per-subscriber timeout (trading worker latency for guaranteed delivery).

Happy to leave this for a follow-up if the team prefers to observe EventChannelDropsTotal behavior in production first.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@kubernetes/controller/internal/resolution/workerpool/workerpool.go` around
lines 98 - 100, The non-blocking broadcast in handleWorkItem can silently drop
events when subscriber channels (created via Subscribe using
wp.SubscriberBufferSize / PoolOptions.SubscriberBufferSize) are full, risking
permanently stalled ResolutionInProgress objects; update handleWorkItem to
either (a) restore a 30s RequeueAfter on controllers that currently return
ErrResolutionInProgress so the controller will retry as a safety net, or (b)
change the broadcast to be blocking with a short per-subscriber timeout (e.g.,
loop with select on send and a time.After) so delivery is retried briefly before
counting a drop and incrementing EventChannelDropsTotal; pick one approach and
implement consistent behavior across the resource/deployer/component controllers
and ensure EventChannelDropsTotal is incremented when a send truly fails.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

kubernetes/controller/cmd/main.go (1)

90-90: Minor: variable name drops the Size suffix.

resolverSubscriberBuffer is slightly inconsistent with the flag name resolver-subscriber-buffer-size and the PoolOptions.SubscriberBufferSize field it maps to. Renaming to resolverSubscriberBufferSize would make the chain flag → var → option field uniform. Purely cosmetic.

Also applies to: 113-115

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@kubernetes/controller/cmd/main.go` at line 90, Rename the local variable
resolverSubscriberBuffer to resolverSubscriberBufferSize so it matches the flag
name resolver-subscriber-buffer-size and the PoolOptions.SubscriberBufferSize
field; update all usages where the flag is parsed and passed into PoolOptions
(the variable declaration and the places where it's assigned or referenced,
e.g., the flag definition and when constructing PoolOptions) to use the new
resolverSubscriberBufferSize identifier for consistent naming.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes