src/content-helper/dashboard-page/pages/traffic-boost/provider.ts (1)

233-237: 🛠️ Refactor suggestion

Clamp maxRetries to prevent negative or non-integer values

options?.maxRetries is accepted as-is. If a caller passes -1, Infinity, or NaN, the while loop never hits the 0 === maxRetries guard, opening the door to an infinite retry loop.

-let maxRetries = options?.maxRetries ?? MAX_FETCH_RETRIES;
+let maxRetries = Number.isFinite( options?.maxRetries as number )
+	? Math.max( 0, Math.floor( options!.maxRetries! ) )
+	: MAX_FETCH_RETRIES;

This keeps the current behaviour for valid inputs (including 0) while safeguarding against pathological values.

src/content-helper/common/content-helper-error.tsx (1)

76-98: Extract no-retry list to a shared constant to avoid per-instance allocation.

noRetryFetchErrors is rebuilt every time ContentHelperError is instantiated. Given that the list is static, declare it once (e.g. as a static readonly property or a module-level const) and reference it from the constructor. This removes needless allocations and keeps the list single-sourced.

-		// Errors for which we should not retry a fetch operation.
-		const noRetryFetchErrors: Array<ContentHelperErrorCode> = [
+// Errors for which we should not retry a fetch operation.
+const NO_RETRY_FETCH_ERRORS: readonly ContentHelperErrorCode[] = [
 			ContentHelperErrorCode.AccessToFeatureDisabled,
 			ContentHelperErrorCode.ParselyAborted,
 			/* … */
 		];
 …
-		this.retryFetch = ! noRetryFetchErrors.includes( this.code );
+		this.retryFetch = ! NO_RETRY_FETCH_ERRORS.includes( this.code );

src/content-helper/editor-sidebar/related-posts/component.tsx (1)

38-44: Avoid duplicating identical MAX_FETCH_RETRIES constants across modules.

The same hard-coded value (1) is now present in several files. Consider exporting a single MAX_FETCH_RETRIES constant from a common utility (e.g. common/retry.ts) so the limit can be adjusted from one place and remains consistent.

src/content-helper/dashboard-widget/components/top-posts.tsx (1)

26-33: Centralise retry constant to prevent drift.

Same comment as for Related Posts: exporting a shared MAX_FETCH_RETRIES avoids future divergence and makes the retry policy discoverable.

src/content-helper/editor-sidebar/performance-stats/component.tsx (1)

38-44: Consolidate retry configuration.

Consider re-using a project-wide constant rather than redefining MAX_FETCH_RETRIES locally.

src/content-helper/dashboard-page/pages/traffic-boost/provider.ts (1)

141-147: Export & centralise the retry constant

MAX_FETCH_RETRIES improves readability, but the same literal is still being introduced in several modules in this PR. To avoid future drift, place it in a shared constants module (e.g. src/content-helper/common/constants.ts) and export it:

-const MAX_FETCH_RETRIES = 3;
+export const MAX_FETCH_RETRIES = 3; // Shared across content-helper modules.

Downstream files can then import { MAX_FETCH_RETRIES } …, giving you a single source of truth.

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro