ValidationElement.validate() raises KeyError: 'error' after removing error via the public props() API

[manu-ns]

First Check

• I added a very descriptive title here.
• This is not a security issue (those should be reported via the security advisory instead).
• This is not a Q&A. I am sure something is wrong with NiceGUI or its documentation.
• I used the GitHub search to find a similar issue and came up empty.

Example Code

from nicegui import ui

input_element = ui.input(value="valid", validation=lambda value: None if value else "required")

input_element.props(remove="error error-message")
input_element.validate()

Description

I am using a validated ui.input and clearing Quasar validation props through NiceGUI's public props() API.

I expect either:

• the public API to reject removal of reserved validation props, or
• validate() to recover gracefully.

What currently happens is that validate() raises:

KeyError: 'error'

This seems to happen because ValidationElement.error later reads self._props['error'], but that key can still be removed through props(remove="error ...").

NiceGUI Version

3.9.0

Python Version

3.12.3

Browser

Chrome

Operating System

Linux

Additional Context

This looks related to #3809, which also hit a ValidationElement KeyError around the reserved error prop. The trigger here seems different: in this case the key can be removed through the public props(remove="error ...") API and the later validate() call then crashes.

[falkoschindler]

Hi @manu-ns, thanks for the report and the nice minimal repro!

Before we decide how to fix this, could you share a bit more about what you're trying to achieve with props(remove="error error-message")? A few things we'd like to understand:

• Are you aware of the error setter (input_element.error = None) for clearing the error message programmatically?
• If yes, what does props(remove=...) give you that the setter doesn't? For example, are you trying to collapse the reserved space Quasar keeps below the input for the error message?
• Or is this more of an exploratory "reset the element" attempt, without a specific visual goal?

The reason we ask: error and error-message are props that ValidationElement manages internally (initialized in __init__ to reserve the bottom space). Removing them through the public props() API puts the element into a state it doesn't expect, which is why validate() later crashes. Depending on your actual goal, the right fix might be hardening the setter, adding a proper API for the use case you have in mind, or both.

[manu-ns]

hey @falkoschindler !
yep, I’m aware of input_element.error = None. The use case is that I need to render custom error content, including a link, instead of a plain error-message.

Using input_element.error = message drives NiceGUI’s normal validation state, but it also sets error-message. That works for plain text, but not for this case where the visible error content is rendered through the error slot.

So what I was trying to do was keep the element in Quasar’s visual error state while leaving error-message unset, because the slot provides the actual rendered content.

The previous workaround used props(remove="error error-message") when clearing that state, which is what exposed the KeyError on the next validate() call.

For now I worked around it by keeping the reserved props present and updating them directly:

target._props["error"] = message is not None
target._props["error-message"] = None
target.update()

That avoids the crash, but relying on _props is exactly what I’d like to avoid.

So from my side, either of these would help:

• harden ValidationElement / props(remove=...) so reserved validation props cannot leave the element in a broken state;
• or expose a public way to set the visual error state while rendering the error content through a custom slot, without also setting error-message.

Happy to adjust the repro if another minimal example would be clearer.

[falkoschindler]

Thanks for the detailed explanation, @manu-ns — the slot use case clarifies a lot. Sharing our findings and a few possible directions; we're genuinely undecided on which (if any) belongs in the library.

Diagnosis

Quasar's error slot only renders when the error-message prop is empty. Since ValidationElement.error setter always writes both error and error-message, the slot never has a chance to render — which is why you reached for props(remove="error error-message") to clear it. The KeyError is then a follow-on: after the prop is removed, the setter reads self._props['error'] with [] on the next validate().

Possible change 1 — defensive hardening

Change the bare [] lookup to .get() so the setter doesn't crash if the prop was removed externally:

-        if self._error == error and self._props['error'] == new_error_prop:
+        if self._error == error and self._props.get('error') == new_error_prop:

Pure robustness, no behavioral change.

Possible change 2 — slot-aware setter

Skip writing error-message when an error slot is registered, so Quasar's slot can render:

         self._props['error'] = new_error_prop
-        self._props['error-message'] = error
+        if 'error' not in self.slots:
+            self._props['error-message'] = error

This makes your scenario work with the natural validation= API, no _props poking required:

input_element = ui.input(validation=lambda value: None if value else 'required')
with input_element.add_slot('error'):
    ui.label('error slot')

API smell this exposes

The validation function returns an error string ('required' etc.), but with an error slot the string is never rendered — only the None / non-None distinction matters. So users end up returning throwaway strings. Worth thinking about whether the validation contract should accept bool returns too, but that's a bigger conversation.

Workaround that works today, no library change

You can opt out of the built-in validation machinery and drive error via a value-change handler:

input_element = ui.input().without_auto_validation()
input_element.on_value_change(lambda e: input_element.props.update(error=not e.value))
with input_element.add_slot('error'):
    ui.label('error slot')

.without_auto_validation() is the key: otherwise _handle_value_change calls validate() after your handler and resets self.error = None, which overwrites your update.

Open question

Given the workaround works today, it's not obvious the library needs to change at all. Change 1 is cheap defensive hygiene. Change 2 is more of a design decision: do we want the built-in validation= API to accommodate the slot pattern, or is that out of scope (you bring your own validation in that case)? Curious to hear your take.