Skip to content

FIX: reject non-finite InputSystem.pollingFrequency (ISX-2837) - #2474

Open
ekcoh wants to merge 3 commits into
developfrom
isx-2837-pollingfrequency-reject-non-finite
Open

FIX: reject non-finite InputSystem.pollingFrequency (ISX-2837)#2474
ekcoh wants to merge 3 commits into
developfrom
isx-2837-pollingfrequency-reject-non-finite

Conversation

@ekcoh

@ekcoh ekcoh commented Aug 17, 2026

Copy link
Copy Markdown
Collaborator

Description

Rejects non-finite values in InputSystem.pollingFrequency. The setter previously guarded only with value <= 0; NaN compares false against everything, so it slipped past (as did +Infinity), got cached, and was returned on every subsequent read — permanently leaving the property at NaN and disabling background polling. The setter now rejects NaN / ±Infinity (and non-positive values) with an ArgumentException.

Fixes ISX-2837. Found by QA while validating unity/unity PR #120254. The engine-side counterpart (native SetAsynchronousInputPollingFrequency) is hardened separately in UUM-149921 / UUM-149922; this PR closes the package-side half.

Testing status & QA

  • Added unit test Devices_CannotSetPollingFrequencyToNonFiniteValue (CoreTests_Devices) asserting NaN, +Infinity, -Infinity, 0, and negative all throw ArgumentException, and that a rejected assignment leaves the previous value untouched.
  • Manual check (no project needed): InputSystem.pollingFrequency = float.NaN; now throws instead of the property reading back NaN.

Overall Product Risks

  • Complexity: Low — a single guard condition.
  • Halo Effect: Low — behavior changes only for inputs that were already invalid (non-finite). Valid frequencies are unaffected.

Comments to reviewers

  • Only behavioral change: NaN / +Infinity now throw ArgumentException (previously silently accepted; -Infinity was already caught by <= 0). No valid input changes behavior.
  • float.IsFinite intentionally avoided (unavailable on netstandard2.0); using IsNaN / IsInfinity, matching existing usage in InputDeviceDebuggerWindow.
  • Cross-refs: engine-side half UUM-149921 / UUM-149922; discovered via unity/unity PR #120254.

Checklist

Before review:

  • Changelog entry added.
    • Explains the change in Changed, Fixed, Added sections.
    • For API change contains an example snippet and/or migration example.
    • JIRA ticket linked, example (case %%). If it is a private issue, just add the case ID without a link.
    • Jira port for the next release set as "Resolved".
  • Tests added/changed, if applicable.
    • Functional tests added (Devices_CannotSetPollingFrequencyToNonFiniteValue).
  • Docs for new/changed API's.
    • Xmldoc cross references are set correctly.
    • Added explanation how the API works.
    • Usage code examples added.
    • The manual is updated, if needed.

During merge:

  • Commit message for squash-merge is prefixed with one of the list:
    • NEW: ___.
    • FIX: ___.
    • DOCS: ___.
    • CHANGE: ___.
    • RELEASE: 1.1.0-preview.3.

@u-pr u-pr Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Harness Review

Ship it

The setter now rejects every non-finite float before it can mutate either stored or native runtime polling state, while preserving the existing rejection of non-positive values. I examined the platform branches, runtime propagation, test coverage, and changelog entry.

Reviewed commit 5912b84

🤖 Helpful? 👍/👎

@Pauliusd01

Copy link
Copy Markdown
Collaborator

It's still reading back as NaN for me (with the warning thrown which is correct) so maybe It's my scene that's wrong. I'll send you the project via dm with instructions

…ISX-2837)

Follow-up to the ISX-2837 guard. No behaviour change.

The original comment justified rejecting +Infinity as the same caching bug
as NaN. It is not. The native backend accepts +Infinity as "poll
continuously" and zero as "disable polling", so rejecting either here is a
deliberate narrowing of a supported native mode and the reason should say
so.

- Explain the +Infinity and zero rejections on their own terms, and drop
  the ////REVIEW asking whether zero should turn off polling - that
  question is answered in the comment now.
- Add the accepted range and an <exception> tag to the public
  InputSystem.pollingFrequency XMLDoc, which had neither.
- Note on the test's +Infinity assertion that it deliberately diverges from
  the native SetPollingFrequency_ShouldAcceptInfinityAsContinuousPolling.
- Reword the changelog to cover both non-finite values and both
  consequences.
@codecov-github-com

codecov-github-com Bot commented Aug 20, 2026

Copy link
Copy Markdown

Codecov Report

All modified and coverable lines are covered by tests ✅

@@            Coverage Diff            @@
##           develop    #2474    +/-   ##
=========================================
  Coverage    78.95%   78.95%            
=========================================
  Files          767      767            
  Lines       140780   140912   +132     
=========================================
+ Hits        111153   111261   +108     
- Misses       29627    29651    +24     
Flag Coverage Δ
inputsystem_MacOS_6000.0 5.30% <0.00%> (-0.01%) ⬇️
inputsystem_MacOS_6000.0_project 77.50% <100.00%> (+<0.01%) ⬆️
inputsystem_MacOS_6000.3 5.30% <0.00%> (-0.01%) ⬇️
inputsystem_MacOS_6000.3_project 77.50% <100.00%> (+<0.01%) ⬆️
inputsystem_MacOS_6000.5 5.29% <0.00%> (-0.01%) ⬇️
inputsystem_MacOS_6000.5_project 77.56% <100.00%> (+<0.01%) ⬆️
inputsystem_MacOS_6000.6 5.29% <0.00%> (-0.01%) ⬇️
inputsystem_MacOS_6000.6_project 77.56% <100.00%> (+<0.01%) ⬆️
inputsystem_MacOS_6000.7 5.29% <0.00%> (-0.01%) ⬇️
inputsystem_MacOS_6000.7_project 77.56% <100.00%> (+<0.01%) ⬆️
inputsystem_Ubuntu_6000.0 5.31% <0.00%> (-0.01%) ⬇️
inputsystem_Ubuntu_6000.0_project 77.41% <100.00%> (+0.01%) ⬆️
inputsystem_Ubuntu_6000.3 5.31% <0.00%> (-0.01%) ⬇️
inputsystem_Ubuntu_6000.3_project 77.41% <100.00%> (+<0.01%) ⬆️
inputsystem_Ubuntu_6000.5 5.30% <0.00%> (-0.01%) ⬇️
inputsystem_Ubuntu_6000.5_project 77.47% <100.00%> (+<0.01%) ⬆️
inputsystem_Ubuntu_6000.6 5.30% <0.00%> (-0.01%) ⬇️
inputsystem_Ubuntu_6000.6_project 77.46% <100.00%> (+<0.01%) ⬆️
inputsystem_Ubuntu_6000.7 5.30% <0.00%> (-0.01%) ⬇️
inputsystem_Ubuntu_6000.7_project 77.47% <100.00%> (+<0.01%) ⬆️
inputsystem_Windows_6000.0 5.30% <0.00%> (-0.01%) ⬇️
inputsystem_Windows_6000.0_project 77.62% <100.00%> (+0.06%) ⬆️
inputsystem_Windows_6000.3 5.30% <0.00%> (-0.01%) ⬇️
inputsystem_Windows_6000.3_project 77.62% <100.00%> (+0.06%) ⬆️
inputsystem_Windows_6000.5 5.29% <0.00%> (-0.01%) ⬇️
inputsystem_Windows_6000.5_project 77.68% <100.00%> (+0.06%) ⬆️
inputsystem_Windows_6000.6 5.29% <0.00%> (-0.01%) ⬇️
inputsystem_Windows_6000.6_project 77.68% <100.00%> (+0.06%) ⬆️
inputsystem_Windows_6000.7 5.29% <0.00%> (-0.01%) ⬇️
inputsystem_Windows_6000.7_project 77.68% <100.00%> (+0.06%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
Assets/Tests/InputSystem/CoreTests_Devices.cs 98.24% <100.00%> (+<0.01%) ⬆️
...ty.inputsystem/InputSystem/Runtime/InputManager.cs 89.05% <100.00%> (+0.04%) ⬆️
...ity.inputsystem/InputSystem/Runtime/InputSystem.cs 82.14% <ø> (ø)

... and 3 files with indirect coverage changes

ℹ️ Need help interpreting these results?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants