Text Input component "default value" stopped populating input field (evaluates correctly, suddenly broke)

My goal: Populate a Text Input component (merchantCharacterIdsInput) dynamically using {{ selectedCharacterIds.value }} in the Default value field.

Issue: The Default value property on the Text Input component has stopped populating text into the input field.

Even though Retool evaluates the JavaScript expression correctly, the input box remains completely blank in both editor and preview modes. This app has been untouched for months/years and suddenly broke today.

  • Property Inspector showing Default value set to {{ selectedCharacterIds.value }}

  • Hover tooltip confirming Retool successfully evaluates the expression to a valid string of IDs ("85931,544687..."):

  • Canvas view showing the input box remaining completely blank despite the evaluated value:

Steps I've taken to troubleshoot:

  • Static String Isolation Test: Replaced {{ selectedCharacterIds.value }} in Default value with a simple hardcoded string (plain text).

    • Result: The input field still remained completely blank.
  • Subcomponent & State Accessibility Test: To verify that the component can read the state, I navigated to the component's subcomponent settings (Label > Caption) and set Caption to {{ selectedCharacterIds.value }}.

    • Result: The caption area rendered the full list of IDs immediately. However, the input box directly adjacent to it remained blank. This confirms the data is available to the component, but the main text input field fails to bind/display its default value.

    • Inspector showing Caption set to {{ selectedCharacterIds.value }}.

    • Canvas view showing the caption rendering the data correctly while the input field remains blank.

3 Likes

Summary

A Text Input's 'Default value' field ({{ selectedCharacterIds.value }}) stopped populating the input; the expression evaluates correctly (it renders in a tooltip and even in the component's Caption subcomponent), but the input box stays blank in both editor and preview—and it remained blank even after substituting a hardcoded static string. The app had been untouched for a long time and appeared to break suddenly.

AI Response

This is expected behavior of the Text Input's 'Default value', which only seeds the value on initial load or reset—once the component already holds a current value (common for a long-lived app with a persisted/cached value), changing the Default value no longer overrides what's displayed, even with a static string. The reference docs confirm the same property represents 'the current or default value,' which is why the source still renders correctly in the Caption but not in the input itself. To force the input to reflect the source, drive it programmatically with textInput.setValue({{ selectedCharacterIds.value }}) or reset it with textInput.resetValue() via an event handler (e.g., when the selection changes). The Retool status page shows no related platform incident affecting Text Input default values around that date.

Sources

:bookmark: The Text Input component for classic apps | Retool Docs
Documents that the Text Input's Default value maps to the 'current or default value' property and provides setValue() and resetValue() methods to programmatically populate or reset the field.
:bookmark: Unexpected behaviour of default values in input
A solved community thread corroborating that an input's default value stops applying once the component holds a current value, with the same programmatic reset/setValue workaround.

The Community Team is testing out a new automation designed to improve resource discovery. Let us know if it's helpful by leaving a :heart: or :+1:. Or by marking this post as the "Solution"! And let us know if you have any feedback here. :rocket:

This issue is impacting many apps across our company. Breaking all updates for data.

+1

Affecting us too. Could result in lots of data being corrupted inadvertently by users when trying to save forms with dynamically populated data via underlying resources.

Thanks for flagging this, everybody! The impact seems to be limited to text inputs that are nested within forms, but we're validating that now and working on a quick fix. I'll provide an update here as soon as that goes live!

4 Likes

In the meantime, if you want to restore previous functionality, you can delete null from the Form Data of any Form container that has Text Input components where the Default Value is not populating correctly.

This is affecting us too! Most critically, our quoting tool that our dealers use!

Can you please explain this workaround?

2 Likes

What we did that seemed to work @maxamillian

  • open up the form in the “inspector”
  • typed in null in the Data Source input box
  • deleted null
    Then the data started populating properly after that

5 Likes

UPDATE: Confirming that the fix is live!


Yes! Thanks for demoing, @brookehale. We have a robust fix in the pipeline that should go live within the hour. :+1:

2 Likes

A belated thank you for this - crisis averted! Cheers

1 Like

Thank you team for the quick resolution!

1 Like

@Darren Can you explain how not updating the status page when there is a major outage/issue is an acceptable practice? For something as major as forms not working due to a bad deploy, users having to navigate to the community to learn of the issue from other users is not acceptable and from the outside feels like a ploy to keep uptime numbers high, especially when uptime numbers for classic apps are barely above 99%.

From what we’re seeing, the issue started approx 2:30 CST and your comment confirmed resolution at 5:17 CST. That is almost 3 hours of downtime that affected every single page of our application and stalled any business processes that go through Retool for the afternoon.

Below is the message from support I am referencing:

We inadvertently shipped a change to Form containers that affected the nested text input components. Due to the assessed severity of the incident, and the quick fix that we were able to apply, we chose not to update the status page.
Our apologies for the disruption, but we really appreciate the patience and the initial report.

That's fair feedback, @paul.narup. :+1: I'll pass it on, regardless, but can also give a bit more context about the decision-making process that goes on behind the scenes whenever a customer issue is found to be a clear regression and escalated.

The on-call team starts by assessing the severity of the issue based primarily on the scope of the impact, the number of affected customers, and the anticipated time to resolution. We require that issues of a certain severity be posted to the status page, but that is otherwise a discretionary step. In this particular case, the relatively quick turnaround - about 100 minutes from escalation to PR - combined with the perceived scope were the primary reasons we decided not to post anything publicly. I can assure you there was nothing duplicitous about this - just humans working hard to resolve the issue as fast as possible.

All that said, I can certainly understand the desire for an "official" way to track issues like this regardless of assessed severity. We've talked a lot about automating the status page pipeline and I think this feedback will be a valuable talking point in those conversations.