Repository navigation
Conversation
… on the last save A save only returns issues from the validators that ran. A custom validator whose HasRelevantChanges returns false is left out of the response. Since the incremental validations were moved into useUpdateIncrementalValidations (PR 3753), the backend validations have been rebuilt from the initial validation and the last save only. An error from an earlier save therefore disappeared as soon as another validator ran, while it still blocked submit. Keep the backend validations grouped by validator in the validation store, and let a save replace only the groups of the validators that ran, as the frontend did before.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Docstring Coverage |  |
Docstring coverage is 25.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 4 functions across 4 files. | Write docstrings for the functions missing them to satisfy the coverage threshold. |
-
Check name Status Explanation Description check The description explains the bug, implementation, scope, related issue, manual testing, automated testing, accessibility decision, documentation decision, and release-process items. It also records te… Title check The title clearly and concisely describes the main change: retaining backend errors from validators that did not run on the latest save. Linked Issues check The changes satisfy issue #4380.backendValidatorGroupspreserves each validator's field validations in the validation store.useUpdateIncrementalValidationsstarts from those groups and replaces …Out of Scope Changes check The changed source files implement the validator-group state flow for the linked issue. The added tests verify the required save behavior. No unrelated implementation or test changes are shown in the … Full details: Description check
-
Explanation
The description explains the bug, implementation, scope, related issue, manual testing, automated testing, accessibility decision, documentation decision, and release-process items. It also records test results and known follow-up work for v9.
Full details: Linked Issues check
-
Explanation
The changes satisfy issue
#4380.backendValidatorGroupspreserves each validator's field validations in the validation store.useUpdateIncrementalValidationsstarts from those groups and replaces only validators returned by the latest save. An empty group clears that validator. Initial validation updates still replace all groups.BackendValidation.test.tsxcovers both retention and clearing behavior.
Full details: Out of Scope Changes check
-
Explanation
The changed source files implement the validator-group state flow for the linked issue. The added tests verify the required save behavior. No unrelated implementation or test changes are shown in the pull request diff.
-
- Fix all pre-merge checks with AI
✨ Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands.
olemartinorg
added
kind/bug
This branch has not been deployed
2 participants
Description
A save only returns issues from the validators that ran. Since #3753,
useUpdateIncrementalValidationsrebuilds the backend validations from the cached initial validations and the last save only. An error from an earlier save therefore disappears from the form when another validator runs on a later save, while the backend still has it and blocks submit. The issue has the steps and screenshots.This PR keeps the backend validations grouped by validator in the validation store, as the ref in
BackendValidation.tsxdid before #3753:backendValidatorGroupsin the store holds the groups.updateBackendValidationsnow takes validator groups instead of data model validations, stores them, and maps them to data model validations itself.BackendValidation.tsxsets the groups. A new fetch of the initial validations (process/next,UpdateShowAllErrors) still replaces them all.useUpdateIncrementalValidationsstarts from the stored groups instead of the cached initial validations, and replaces only the groups in the last save. It is used after form data saves and after attachment tags are saved, so both keep the groups now.processedLast, the task validations andwaitForValidationare unchanged.Same steps as in the issue, with app-frontend 4 from the CDN and with this branch:
4)v9 has the same code in
src/App/frontendin altinn-studio, and also builds the component validations from the cached initial validations. I will make a separate PR there.Related Issue(s)
Verification/QA
kind/*andbackport*label to this PR for proper release notes groupingBackendValidation.test.tsxrenders a form with two inputs and answers each save with the validators that ran:main.maintoo, and checks that the change does not keep errors a validator has cleared.yarn tsc,yarn lintand the fullyarn testpass locally on Node 22 (168 test suites and 3646 tests passed, 1 suite and 61 tests skipped). Every changed line and branch in the three source files is covered.Manual test in localtest with a copy of one of our apps (Altinn.App 8.12.11) with two validators as in the issue. The local builds were loaded through localtest's
frontendVersioncookie:main(3ef668f) built locally: the phone number error disappears when the email is saved./validatereturns the same issue in all three.Summary by CodeRabbit