fix(settings): reject rateLimits with non-positive period

[Ferryx349]

Description

• Validate period > 0 for every rateLimits[] entry (and admin.loginRateLimits) in validateSettings(), matching existing pow.periodMs checks.
• Prevents misconfiguration where period: 0 yields a bogus 1 ms backoff hint and breaks EWMA decay.

Related Issue

closes :- #811

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

• Non-functional change (docs, style, minor refactor)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my code changes.
• I added a changeset, or this is docs-only and I added an empty changeset.
• All new and existing tests passed.

[changeset-bot]

🦋 Changeset detected

Latest commit: 0f67db4

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
nostream	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; both previous findings are addressed and no new blocking issues remain.

Summary

The PR rejects non-positive periods across all eight rate-limit settings paths.

• Settings validation rejects rate limits with non-positive periods.

_{Reviews (2) · Last reviewed commit: "fix(settings): harden rateLimits validat..." · Reviewed by Greptile}

[coveralls]

Coverage is 73.251% — fix/811-validate-rate-limit-period into main. No base build found for main.

[chappie-daemon]

Post-merge review: fix(settings): reject rateLimits with non-positive period

Went through the diff against #811. Verdict: approve-level — clean, minimal, exactly what the issue asked for.

What's good

• Covers all eight arrays, including admin.loginRateLimits — matches the issue's affected list exactly, nothing missed.
• Style-consistent with the existing checks: pushes { path, message } issues, and the message ('period must be greater than 0') mirrors the existing 'periodMs must be greater than 0'. The !(entry.period > 0) form matches the codebase's existing negated-comparison style and also catches NaN/undefined/non-numeric junk, not just 0 and negatives.
• The null/array entry guard is a sensible defensive addition beyond the issue's ask — a null entry now yields a clear validation issue instead of a TypeError on entry.period, and it's tested.
• Changeset included ("nostream": patch), so this rides the 3.4.0 release.
• Tests are table-driven across all eight arrays (mixing 0 and -1), plus a positive acceptance case and the null-entry case. Good coverage for the size of the change.

Nits (non-blocking)

1. The PR body template is mostly unfilled — "How Has This Been Tested?" is empty even though tests were added. The diff shows the tests, so nothing is actually unverified, but the body should say so.
2. closes :- #811 has a formatting artifact (:-). The link still registered (it shows in the issue timeline), so cosmetic only.
3. Footnote, out of scope: Infinity passes the check (Infinity > 0), which would later surface as a non-numeric backoff hint and zero EWMA decay. Only reachable via YAML's .inf (JSON can't express it), so pathological — noting for completeness, not asking for a change.

---

From Muse