refactor: standardize runtime guard patterns with lodash-es

[Draculabo]

Summary

This PR standardizes runtime guard patterns by replacing ad-hoc typeof checks and trim-based empty checks with lodash-es predicates.

What changed

• Replaced runtime type checks with isString/isNumber/isBoolean/isFunction/isObjectLike/isUndefined.
• Normalized empty-string checks to isEmpty(value.trim()) where applicable.
• Applied the same guard style across runtime modules, IPC handlers, and tests.
• Added an agent skill summary for future consistency:
  • .agents/skills/lodash-es-runtime-guards/SKILL.md

Verification

• rg -n "typeof\\s+[^\\n]+(?:===|!==)\\s*'" src returns no runtime typeof comparisons.
• npm run type-check passes.

[codereviewbot-ai]

Potential issue with formatting credits value:

The code uses credits.toFixed(2) without verifying that credits is a valid number. If credits is NaN, undefined, or otherwise invalid, this could result in misleading output or a runtime error. Consider adding a stricter check:

if (isNumber(credits) && !isNaN(credits)) {
  toast({
    title: t('cloud.toast.quotaRefreshed'),
    description: `AI credits: $${credits.toFixed(2)}`,
  });
  return;
}

This ensures only valid numbers are formatted and displayed.

[codereviewbot-ai]

Error Handling Issue: Throwing an error (throw new Error) for invalid collisionPadding values inside a React component can cause the entire component tree to unmount if not caught, leading to poor user experience. Instead, consider logging a warning or defaulting to a safe value:

if (isNumber(collisionPadding) && collisionPadding < 0) {
  console.warn('collisionPadding must be a non-negative number');
  collisionPadding = 8; // fallback to default
}

This approach prevents disruptive errors and maintains application stability.

[codereviewbot-ai]

Type Validation Issue: The use of isObjectLike from lodash for validating collisionPadding may allow non-plain objects (such as arrays or Date objects), which could lead to unexpected behavior. To ensure only plain objects with the expected keys are accepted, use a stricter check:

if (typeof collisionPadding === 'object' && collisionPadding !== null && !Array.isArray(collisionPadding)) {
  // proceed with validation
}

This ensures the prop conforms to the intended shape and prevents runtime errors.

[codereviewbot-ai]

In normalizeDeviceHistory, invalid entries (non-objects or entries with invalid/missing profiles) are silently skipped. This could mask underlying data issues and make debugging difficult if device history is unexpectedly incomplete.

Recommendation: Consider logging or counting skipped entries for diagnostics, or at least returning information about how many entries were ignored. For example:

if (!profile) {
  logger.warn(`Skipped device history entry with invalid profile at index ${i}`);
  continue;
}

This will help with maintainability and troubleshooting.

[codereviewbot-ai]

Issue: Lack of Data Validation During Restore

When restoring backup data, the code directly writes values from the backup into the database without validating their structure or content. If the backup file is corrupted or has been tampered with, this could result in invalid or malicious data being persisted, potentially leading to application errors or security vulnerabilities.

Recommendation:
Before writing each value to the database, validate that it conforms to the expected schema for that key. For example, use a schema validator or type guard to ensure the data is well-formed:

if (validateKeyValue(key, value)) {
  // proceed with insert
} else {
  logger.warn(`Invalid data for key: ${key}, skipping restore for this key.`);
  continue;
}

Implement validateKeyValue to check the structure and type of each value according to your application's requirements.

[codereviewbot-ai]

In the SSE next handler, the chunk is stringified if not a string, which could result in unexpected output if the chunk is a complex object (e.g., an object with circular references or large nested structures). This could cause client-side parsing issues or performance problems.

Recommendation: Ensure that the chunk is properly serialized to a format expected by the client (e.g., JSON) and consider validating the chunk's structure before writing it to the response. If the chunk is not serializable, log an error and skip sending it.

[codereviewbot-ai]

Potential ambiguity in key construction:
The buildLockoutKey method uses isEmpty(model?.trim() ?? '') to determine whether to include the model in the key. If the model is a whitespace-only string, it is treated as empty, which could lead to ambiguous keys (e.g., accountId: vs accountId). Consider explicitly handling whitespace-only model names or rejecting them to avoid ambiguity:

if (model && model.trim() !== '') {
  return `${accountId}:${model.trim()}`;
}
return accountId;

[codereviewbot-ai]

Hardcoded minimum retryAfterSec may lack flexibility:
The setLockoutUntil method enforces a minimum retryAfterSec of 2 seconds. While this prevents immediate retries, it may not be optimal for all use cases. Consider making this value configurable or documenting the rationale for this choice to improve maintainability and adaptability.

[codereviewbot-ai]

Potential Data Race with Shared Mutable State

The use of let cachedUserAgentResolution and let pendingUserAgentResolution as module-level variables introduces a risk of data races in concurrent environments. If multiple asynchronous calls to resolveRequestUserAgent or related functions occur simultaneously, it is possible for the cache or pending promise to be set or read inconsistently, leading to redundant resolutions or inconsistent results.

Recommendation:
Consider using a concurrency-safe mechanism (such as a mutex or atomic operations) to guard access to these shared variables, or refactor to avoid shared mutable state if possible.

[codereviewbot-ai]

Inconsistent Response Handling in fetchTextPayload

The code stringifies non-string response.data values before returning them. If the remote endpoint returns an object or other non-string payload, this may result in an unexpected format for downstream consumers, potentially causing subtle bugs or incorrect user agent strings.

Recommendation:
Validate the response type more strictly and consider returning null or throwing an error if the payload is not a string, unless there is a clear use case for stringifying arbitrary data.