Summary

This PR fixes stale validation UI in DateInput and DateTimeInput when a clear_on_submit form is submitted. It also improves DateTimeInput initialization so temporary selection state is seeded from the correct initial committed value.

Code Quality

The implementation is clean and follows existing widget-state patterns:

• DateInput now resets local error state via onFormCleared, which directly addresses the stale tooltip/error styling bug.
• DateTimeInput now resets pending state on form clear and initializes pending/previous committed state from the same source of truth used by the widget manager flow.
• No problematic side effects, unsafe mutations, or anti-patterns were introduced in the changed files.

Test Coverage

Coverage is good at the unit-test layer for the regression:

• Added focused tests in frontend/lib/src/components/widgets/DateInput/DateInput.test.tsx and frontend/lib/src/components/widgets/DateTimeInput/DateTimeInput.test.tsx that verify error state is cleared after form submit/clear.
• Existing e2e coverage already exercises datetime form reset behavior, but there is still no dedicated e2e assertion for this exact regression path (invalid value -> error visible -> form submit clears error UI), especially for DateInput.

Backwards Compatibility

No API or protocol changes were introduced. Behavior changes are limited to client-side UI state reset in form-clear flows and are backwards compatible with expected clear_on_submit semantics.

Security & Risk

No security concerns identified. Regression risk is low and localized to frontend widget state synchronization during form-clear events.

Accessibility

No new accessibility issues identified in the diff. The change does not alter keyboard interaction patterns, semantics, or accessible naming.

Recommendations

1. Add one e2e scenario per widget (st.date_input, st.datetime_input) that explicitly verifies error UI is removed after clear_on_submit form submission.

Verdict

APPROVED: The fix is targeted, low-risk, and adequately validated with unit tests; it is ready to merge.

This is an automated AI review by gpt-5.3-codex-high. Please verify the feedback and use your judgment.

Summary

This PR fixes a bug where validation error states (red border, error tooltip) persist in DateInput and DateTimeInput widgets after a form with clear_on_submit=True is submitted. The root cause is that the form-clear path resets the widget value via useBasicWidgetState but never invokes handleChange, which is the only place that clears the error state. The fix registers onFormCleared callbacks with useBasicWidgetState to explicitly clear stale validation UI on form clear.

Changed files:

• DateInput.tsx — adds a resetError callback passed as onFormCleared to clear the error state.
• DateTimeInput.tsx — adds an onFormCleared callback that resets pendingDate to the default (which clears the derived error memo), and refactors pendingDate/prevCommittedDate initialization to use a helper that replicates the hook's init logic.
• DateInput.test.tsx / DateTimeInput.test.tsx — adds one test each verifying the error clears on form submit.

Code Quality

DateInput.tsx — Clean and minimal. The resetError callback is properly memoized with useCallback([], []) (stable since setError from useState is stable). Reusing resetError() inside handleChange instead of the inline setError(null) is a nice consistency improvement. The alphabetically-sorted dependency array is a minor style improvement.

DateTimeInput.tsx — The changes are sound but more involved:

1. getInitialCommittedDate (line 79–86): This helper duplicates the initialization logic from useBasicWidgetState (getStateFromWidgetMgr ?? (setValue ? getCurrState : getDefault)). This is necessary because pendingDate and prevCommittedDate must be declared before useBasicWidgetState (so setPendingDate is available for the onFormCleared callback), and these states need the same initial value. The duplication is pragmatic but introduces a coupling — if useBasicWidgetState's initialization logic changes, this could silently drift. A brief comment noting this coupling would be helpful.

2. Initialization with separate function calls (lines 89–96): useState(getInitialCommittedDate) is called twice, producing two distinct Date objects for the same timestamp. This means committedDate !== prevCommittedDate will be true on the first render, triggering the sync block once on mount. This is harmless (React handles setState-during-render correctly, and the sync stabilizes in a single extra render pass) but is a behavioral difference from the original code where both were initialized with the same committedDate reference.

3. Inline useCallback for onFormCleared (line 109–111): The callback depends on [element], which changes identity on each protobuf message. This is consistent with how other widgets handle element-dependent callbacks and is fine since useFormClearHelper already re-subscribes on element changes.

Test Coverage

Both new tests follow a solid pattern:

1. Render widget inside a form with clear_on_submit=True
2. Type an out-of-range date to trigger validation error
3. Assert error tooltip is visible (positive assertion)
4. Submit the form
5. Assert error tooltip is gone (negative/anti-regression assertion)
6. Assert input value resets to default

The tests use appropriate RTL patterns: userEvent for interactions, getByTestId/queryByTestId for presence/absence checks, waitFor for async state changes, and act for widget manager operations.

Minor gap: There are no E2E tests for this scenario. Given this is a focused bug fix with good unit test coverage, this is acceptable, but E2E coverage for date validation in clear_on_submit forms would strengthen confidence in the future.

Backwards Compatibility

No breaking changes. The onFormCleared callback is an optional parameter in useBasicWidgetState that was already supported. The fix only adds behavior (clearing error state on form clear) without changing any existing behavior paths.

Security & Risk

No security concerns. The changes are purely UI state management (clearing local React state on form clear). No new data flows, network calls, or user data handling introduced.

Regression risk: Low. The DateInput change is minimal (just clearing error state). The DateTimeInput change is slightly riskier due to the initialization refactor, but the sync block (committedDate !== prevCommittedDate) provides a safety net that reconciles pendingDate with the committed value regardless of initialization.

Accessibility

No accessibility impact. The changes only affect when error states are cleared, not how they are displayed. The error tooltip mechanism (which uses proper ARIA patterns via stTooltipErrorHoverTarget) remains unchanged.

Recommendations

1. Add a comment noting the initialization coupling in DateTimeInput.tsx at getInitialCommittedDate (line 79), e.g.: "Mirrors the initialization logic from useBasicWidgetState — keep in sync if that hook's init changes."

2. Consider resetting isEmpty in DateInput's onFormCleared: Currently, only error is reset. If a user clears the input (making isEmpty = true) and then submits the form, isEmpty remains true even though the value has been reset to the default. This is a pre-existing issue and not a regression from this PR, but fixing it alongside the error state would be a natural enhancement.

3. Consider E2E test coverage: Adding a test case to e2e_playwright/st_date_input_test.py (and/or st_datetime_input_test.py) that validates the error clears on form submit with clear_on_submit=True would provide end-to-end confidence. This could be done as a follow-up.

Verdict

APPROVED: Clean, well-tested bug fix that correctly clears stale validation error states on form clear, following established patterns from other widgets (e.g., NumberInput). The minor observations above are non-blocking.

This is an automated AI review by opus-4.6-thinking.