The v2.0.0 Vue scaffold still emits LoginProps { errors: None } and RegisterProps { errors: None }. Those explicit props overwrite the validation errors seeded from the session, so invalid credentials can return to the form without displaying the error.
Verified by generating a Vue project with the CLI rebuilt from release commit 3229aa9af542c991196274fa3c235cdce88a68e2 and tracing the released source:
- The auth controller supplies
errors: None on both GET pages.
InertiaProps serializes every field, making this errors: null.
- Inertia response resolution seeds session errors, then inserts explicit prop values over the same keys.
Expected: the default login/register pages preserve framework-provided flashed validation errors. Remove the explicit null props or otherwise ensure they cannot mask the framework error bag, and correct the controller comment claiming the client merges those errors automatically.
Suggested regression: submit invalid credentials and invalid registration data, follow the Inertia redirect, and assert the field errors are visible. Verify an initial clean GET still renders correctly.
Verification limit: this audit inspected the generated files and source; it did not run a fresh 2.0.0 browser reproduction. The directory starter previously encountered this behavior and fixes it by omitting explicit errors props.
Sources:
The v2.0.0 Vue scaffold still emits
LoginProps { errors: None }andRegisterProps { errors: None }. Those explicit props overwrite the validation errors seeded from the session, so invalid credentials can return to the form without displaying the error.Verified by generating a Vue project with the CLI rebuilt from release commit
3229aa9af542c991196274fa3c235cdce88a68e2and tracing the released source:errors: Noneon both GET pages.InertiaPropsserializes every field, making thiserrors: null.Expected: the default login/register pages preserve framework-provided flashed validation errors. Remove the explicit null props or otherwise ensure they cannot mask the framework error bag, and correct the controller comment claiming the client merges those errors automatically.
Suggested regression: submit invalid credentials and invalid registration data, follow the Inertia redirect, and assert the field errors are visible. Verify an initial clean GET still renders correctly.
Verification limit: this audit inspected the generated files and source; it did not run a fresh 2.0.0 browser reproduction. The directory starter previously encountered this behavior and fixes it by omitting explicit errors props.
Sources:
suprnova/suprnova-macros/src/inertia.rs
Line 74 in 3229aa9
suprnova/framework/src/inertia/response.rs
Line 1452 in 3229aa9