Unintended evaluation of query changes

[mprobst]

I am working on getting rid of two errors that keep bugging me.

I have a select component that triggers two queries updating two tables (hours and expenses). This works like a charm.

However I get two errors in the console which are associated with two insert-Queries that are only directly called by two actions triggered by buttons.

However, the two insert-Queries depend, amongst others, on the value of the select component and I suspect that is is causing trouble.

Am I able to suppress these changeset updates or is there another possibility to prevent the automatic evaluation of these values?

[Shawn_Optipath]

Hi @mprobst,

It looks like your unintended evaluation is likely because these bindings reference .selectedItem directly—so when the component changes, Retool evaluates them even if you didn’t trigger the query.

You can make them safe and avoid triggering errors by adding optional chaining (?.) so they don’t evaluate until there’s actually a value:

{{ selectProjectHourItem.selectedItem?.id }}
{{ selectProjectHourItem.selectedItem?.code }}
{{ selectTaskHourItem.selectedItem?.task_id }}
{{ selectTemplate.selectedItem?.id }}
{{ numberInputHoursHourItem.value }}
{{ textInputNotesHourItem.value }}

[mprobst]

Thanks, that worked great.

Now I am struggling at a similar corner related to change sets:

The query updateHourEntry is related to a change set of tableHours and I suspect this is causing trouble.

Questions marks in {{ tableHours.changesetArray}} do not work.

[Shawn_Optipath]

The green {{ tableHours.changesetArray }} looks fine. The error is coming from tableHours.selectedRow.id being read while there’s no row selected. So your update query is being triggered by the template change, and somewhere inside updateHourEntry (or a pre/post step) you still reference tableHours.selectedRow.id.

Remove any dependency on selectedRow inside updateHourEntry.
For a Bulk update via a primary key, you don’t need selectedRow at all. Each object in changesetArray already includes the PK (id). There is also an option to include all columns in a changesetArray.

If you truly need it anywhere, do as above {{ tableHours.selectedRow?.id }}.

If you are still having issues, please post your script that triggers your queries.

[mprobst]

Thanks for your reply. I just don't find any reference to tableHours.selectedRow.id in updateHourEntry.

[Shawn_Optipath]

How do you trigger this? Search the whole app for tableHours.selectedRow.id. It should be in one of these places:

• updateHourEntry query (GUI fields, SQL, “Enabled when”, “Only run when inputs change”, or Watched inputs)

• An event handler that runs right before/after updateHourEntry

• A transformer/JS query that updateHourEntry calls

Can you share the script that triggers this? If you still can't find it maybe remove your on success query temporarily.

[mprobst]

It's triggered by only one component tableHours:

And there I see it only in the save action, which makes sense:

I found out that it primarily happens when the table is empty. As soon as there are values, there is no issue.

[Shawn_Optipath]

This points to the Save action pre-evaluating its bindings on render (even when not clicked). Somewhere in the Save config / mapped query a binding still touches tableHours.selectedRow.id (or anything that assumes a row exists). When the table is empty, selectedRow is null → boom.

Quick fixes that usually stop this:

Remove the Table’s built-in Save and use your own “Save” button:

Button onClick:

if (!tableHours.changesetArray?.length) {
  utils.showNotification({ title: "Nothing to save" });
  return;
}
await updateHourEntry.trigger();

[mprobst]

So, I implemented the save action you provided but still got the error. Now I found the problem: I fiddled around with different query action types in the beginning using "Update an existing record" instead of "Bulk update via a primary key":

I switched back this morning and found still key-value-pairs floating around:

After their deletion (interestingly I cannot delete the last key, so "notes" is still there but without value) it now works fine.
I wonder if key value pairs should be deleted upon changing the query action type?

[Shawn_Optipath]

Glad you found it! Don't hesitate to reach out if you come across any other issues.