FIX: ISXB-1674 - Input actions asset not converted correctly when upgrading from 1.14.1 (Regression)

[AswinRajGopal]

Description

Bug: https://jira.unity3d.com/browse/ISXB-1674
Port: 1.14.X

Preserve original tokens and only touch the enum values. That means processor names, order, legacy processors, and formatting survive unchanged so the editor no longer collapses or marks them “Obsolete”.
Avoid whole string rewrites, which previously caused mismatches between what the editor expected and what was written back and only assign a new processor string if something actually changed.

Testing status & QA

Verified manually with the attached repro project.

Overall Product Risks

Complexity: 0
Halo Effect: 0

Comments to reviewers

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 Area_CanDoX, Area_CanDoX_EvenIfYIsTheCase, Area_WhenIDoX_AndYHappens_ThisIsTheResult.
  • Performance tests.
  • Integration tests.
• 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.

After merge:

• Create forward/backward port if needed. If you are blocked from creating a forward port now please add a task to ISX-1444.

[codecov-github-com]

Codecov Report

Attention: Patch coverage is 91.22807% with 5 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...UITKAssetEditor/Views/NameAndParametersListView.cs	25.00%	3 Missing ⚠️
...nputsystem/InputSystem/Actions/InputActionAsset.cs	96.77%	1 Missing ⚠️
...tsystem/InputSystem/Utilities/NameAndParameters.cs	87.50%	1 Missing ⚠️

@@             Coverage Diff             @@
##           develop    #2244      +/-   ##
===========================================
+ Coverage    68.14%   76.74%   +8.60%     
===========================================
  Files          367      465      +98     
  Lines        53685    87945   +34260     
===========================================
+ Hits         36584    67496   +30912     
- Misses       17101    20449    +3348     

Flag	Coverage Δ
inputsystem_MacOS_2021.3	5.91% <0.00%> (?)
inputsystem_MacOS_2021.3_project	78.04% <10.25%> (?)
inputsystem_MacOS_2022.3	5.37% <0.00%> (?)
inputsystem_MacOS_2022.3_project	74.58% <9.30%> (?)
inputsystem_MacOS_6000.0	5.18% <0.00%> (?)
inputsystem_MacOS_6000.0_project	76.55% <91.22%> (?)
inputsystem_MacOS_6000.2	5.18% <0.00%> (?)
inputsystem_MacOS_6000.2_project	76.55% <91.22%> (?)
inputsystem_MacOS_6000.3	5.18% <0.00%> (?)
inputsystem_MacOS_6000.3_project	76.55% <91.22%> (?)
inputsystem_MacOS_6000.4	5.18% <0.00%> (?)
inputsystem_MacOS_6000.4_project	76.55% <91.22%> (?)
inputsystem_Ubuntu_2021.3	5.91% <0.00%> (?)
inputsystem_Ubuntu_2021.3_project	77.95% <10.25%> (?)
inputsystem_Ubuntu_2022.3	5.37% <0.00%> (?)
inputsystem_Ubuntu_2022.3_project	74.38% <9.30%> (?)
inputsystem_Ubuntu_6000.0	5.19% <0.00%> (?)
inputsystem_Ubuntu_6000.0_project	76.36% <91.22%> (?)
inputsystem_Ubuntu_6000.2	5.19% <0.00%> (?)
inputsystem_Ubuntu_6000.2_project	76.36% <91.22%> (?)
inputsystem_Ubuntu_6000.3	5.19% <0.00%> (?)
inputsystem_Ubuntu_6000.3_project	76.36% <91.22%> (?)
inputsystem_Ubuntu_6000.4	5.19% <0.00%> (?)
inputsystem_Ubuntu_6000.4_project	76.37% <91.22%> (?)
inputsystem_Windows_2021.3	5.91% <0.00%> (?)
inputsystem_Windows_2021.3_project	78.18% <10.25%> (?)
inputsystem_Windows_2022.3	5.37% <0.00%> (?)
inputsystem_Windows_2022.3_project	74.72% <9.30%> (?)
inputsystem_Windows_6000.0	5.18% <0.00%> (?)
inputsystem_Windows_6000.0_project	76.69% <91.22%> (?)
inputsystem_Windows_6000.2	5.18% <0.00%> (?)
inputsystem_Windows_6000.2_project	76.69% <91.22%> (?)
inputsystem_Windows_6000.3	5.18% <0.00%> (?)
inputsystem_Windows_6000.3_project	76.69% <91.22%> (?)
inputsystem_Windows_6000.4	5.18% <0.00%> (?)
inputsystem_Windows_6000.4_project	76.69% <91.22%> (?)

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

Files with missing lines	Coverage Δ
...ests/InputSystem.Editor/CustomProcessorEnumTest.cs	84.48% <100.00%> (ø)
...nputsystem/InputSystem/Actions/InputActionAsset.cs	84.91% <96.77%> (+10.82%)	⬆️
...tsystem/InputSystem/Utilities/NameAndParameters.cs	92.59% <87.50%> (-0.56%)	⬇️
...UITKAssetEditor/Views/NameAndParametersListView.cs	65.38% <25.00%> (-0.98%)	⬇️

... and 98 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ekcoh]

I noticed this PR title was incorrect so I changed it to remove that failure.

[ekcoh]

Thanks for looking into this, my main comment at this review round is to add inline comments explaining why we need to do the different parts since it is not clear to me from the code. I think this is important to make sure its maintainable.

[LeoUnity]

There are a few things you mention in the PR description that I don't understand why they are needed:

Preserve original tokens and only touch the enum values

Formatting survive unchanged
I don't understand why this would be a requirement, I believe that if the user uses our editor to edit the asset that was written manually and has custom formatting that will overwrite the users formatting. Trying to parse json with string replaces, regex is a losing battle, the only way this won't be brittle is by parsing it, converting the data and serializing it back to json.

Avoid whole string rewrites, which previously caused mismatches between what the editor expected
As above, I don't understand why do we want to avoid string rewrites, my current thinking is that we didnt catch this for 2 reasons, we are not reusing the parsing and serializing funcitons that is used elsewhere, and we didnt test this case.

I believe the proper way of moving forward here is that we use the exact same code to parse and serialize json for this type that is used elsewhere in the editor, if we try to do anything different we are creating an opportunity for a bug to be hidden here.

[ekcoh]

Same comment as @LeoUnity, let's complement the test by making sure it parses correctly (logically) and then we can conclude this I believe.

[LeoUnity]

Missing an automated test case that reproduces the issue we are trying to fix here.

[ekcoh]

Thanks for iterating on this and good to see it gets simpler and simpler. The test case still confuses me though. Providing a pseudo example of what I consider to be a stronger test.

[ekcoh]

Can you document what the intent of this test case is inline in code?

My interpretation is that you want to verify that processors defined in a certain way in .inputaction json are parsed/preserved correctly when imported (with migration)? If this is the case I suggest you convert this into a functional test instead of doing a lot of string comparisons. Here is a rough example (coded directly into web interface so it may contain errors but hope you get the idea):

const string legacyJson = "<as before>"; // Consider including binding in JSON to avoid writing code for it
var asset = InputActionAsset.FromJson(legacyJson);
var gamepad = InputSystem.AddDevice<Gamepad>();
var action = asset.FindAction("Player/Move");
action.Enable();

// Make sure deadzone processor is applied
Set(gamepad.leftStick, new Vector2(InputSystem.settings.defaultDeadzoneMin * 0.9f, 0.0f));
Assert.That(action.ReadValue<Vector2>(), Is.Equal(Vecto2.zero)); // Filtered by deadzone

// Make sure invert processor is applied
Set(gamepad.leftStick, new Vector2(1.0f, 0.0f));
Assert.That(action.ReadValue<Vector2>(), Is.Equal(-Vector2.right)); // Inverted

// Make sure custom processor is applied
Set(gamepad.leftStick, new Vector2(0.5f, 0.0f));
Assert.That(action.ReadValue<Vector2>(), Is.Equal(something)); // Not sure how custom should change value, so change this to what is appropriate

Ideally order dependency can be proven through the same test case.

[AswinRajGopal]

Sure I'll change it into a functional test.

[ekcoh]

Do you see any pros/cons with changing approach? Would such a functional test miss some aspect of this?

[AswinRajGopal]

My view about authoring a regression test is to cover only the migration case where we actually verify that a JSON with a custom processor and some neighboring processors like stickdeadzone or invertVector are parsed properly after migration.

The functional tests already exists which covers most of the functionals in the input system generic tests. However it will be robust to club both of these for this case.

[ekcoh]

OK, that is also fine so keep this if you want. Not sure @LeoUnity has additional perspective?
Not sure we already test this specific processor order somewhere else?

[LeoUnity]

PR looks good, there are a few failing CI jobs.

[ericksson]

The Android jobs are broken and stuck - see https://unity.slack.com/archives/C94RMJJ5T/p1760644095487229

Follow that thread to see when Lukas has a fix for the issue. Please refrain from rerunning the tests until the fix is available and you have it merged in this branch.