Goal: Fix urgent bug causing all most of our queries (dependent on some input in the app which is initially null) to start notifying errors on page load.
Steps: Revert to previous deployed releases of apps. Log-in, log-out. Confirm no account-level settings have been changed.
Details: Sometime around/after 5pm EST today, most of our apps starting throwing query errors on page load. This happened automatically and does not seem related to a change on our end, as it affected most of our apps (even old untouched ones).
It almost feels like "Run this query on page load" somehow got flipped on for all of our queries (or a similar rollout behind the scenes that may have caused this)
Previously, these queries depending on an input did not automatically run on page load, and only ran when we changed the input. In the past, even though it was set to automatic, it didn't run and throw errors until we actually changed the value {{ userTable.selectedRow.id }}. As a result of this bug, many apps started throwing page-load query errors.
While we could likely go and refactor all of our queries to use "Manual" run behavior and input change event handlers to solve this -- we'd still like to figure out why this broke randomly today. Previously, the "Automatic" run behavior didn't happen on load for a resource until the input it was depending on finally had a non-null value.
Spending a bit more time looking at this today, I don't think the blast radius of the problem is just failure notifications. We are seeing more invalid queries to our REST apis (like GET /users/{{ userInput.value }} now sending a GET /users/null to our REST api on page load)
Hey all! Thanks for flagging this so quickly. We're pretty sure we've identified the specific change responsible for this behavior but want to clarify a few things before taking any action.
To start, all queries with an "Automatic" run behavior - even those that are dependent on user inputs - have typically always run on initial page load. I've confirmed by testing on several older releases. The change we recently made is that these queries now correctly throw an error notification when the "Show notification on failure" option is enabled.
That said, all queries are configured by default to show a failure notification, so it's understandable why this seems like such a breaking change. In theory, though, you can restore the previous functionality of your apps by just toggling that setting off. The better option (and best practice) is to disable the query entirely via the "Advanced " settings until certain conditions are met.
I hope that background helps! We are gathering feedback and evaluating next steps, but I would nonetheless strongly recommend that you dynamically disable queries that depend upon inputs by verifying the existence of said inputs.
To start, all queries with an "Automatic" run behavior - even those that are dependent on user inputs - have typically always run on initial page load
Interesting, thanks for confirming! I must have convinced myself otherwise, meaning these have secretly been failing and running automatically for a long time now, but just not surfaced like you noted. I'll go ahead and add those Disable query requirements on all of our automatic queries depending on initially null component input.
I think this feels better than switching to "Manual" run behavior for all of our queries which depend on component input. If we were to do that, we'd need to add a swarm of change handlers to all of our inputs.
In theory, though, you can restore the previous functionality of your apps by just toggling that setting off. The better option (and best practice) is to disable the query entirely via the "Advanced " settings until certain conditions are met.