Embedded app with _releaseVersion executes published-release query definitions

💬 Queries and Resources
1

Embedded app with _releaseVersion executes published-release query definitions

We have found what appears to be a release-version mismatch when embedding a Retool app and pinning it to a non-published release.

Setup

  • Retool Cloud

  • Classic App

  • Published release: 1.5.7

  • Embedded app requested with a newer release, e.g. 1.7.9

  • The embedded UI correctly appears to use the requested newer release.

Observed behaviour

For queries executed from the embedded app, the request contains:

  • isEmbedded: true

  • releaseVersion: null

The query appears to be executed using the published release’s query definition, while parameter values originate from the newer requested release.

In our reproducible example:

  • Published 1.5.7 query has 5 parameter placeholders.

  • Newer 1.7.9 query has 6 values.

  • The values are applied positionally to the 1.5.7 query definition.

  • This causes a PostgreSQL syntax error in our example.

We reproduced the resulting SQL independently by applying the newer release’s values to the published release’s query template.

Important potential impact

The concern is not only that queries can fail.

If query definitions changed between releases but the resulting SQL remains syntactically valid, parameters could potentially be applied to the wrong placeholders and cause incorrect writes without producing an error.

For that reason, this may have data-integrity/security implications rather than being only an embedding/UI issue.

Workaround

Publishing the newer version, or using a duplicate app where that version is published, appears to avoid the mismatch.

Pinning the embedded application to the currently published 1.5.7 also works correctly.

Questions

  1. Is _releaseVersion expected to pin both the UI and server-side query definitions for embedded Classic Apps?

  2. Is releaseVersion: null on query execution expected when the embedded app was opened with a specific release?

  3. Does the same behaviour affect normal Retool URLs using _releaseVersion, or only embedded apps?

  4. Is duplicating the app and publishing the test version currently the recommended safe workaround?

We can provide the exact network request/response and a minimal reproduction privately if useful.

2

Summary

On a Retool Cloud Classic app embedded and pinned to a non-published release via _releaseVersion (e.g. 1.7.9 while 1.5.7 is published), the UI loads the requested newer release but queries execute with releaseVersion: null against the published release's query definition, applying the newer release's parameter values positionally to the older template — causing SQL errors and raising potential data-integrity concerns.

AI Response

This report aligns with known behavior where queries executed outside a fully published release don't reliably run that release's query definition — they tend to resolve against the live/published version, which staff have acknowledged as a gap and filed internally. The classic-app _releaseVersion parameter is documented to pin the app version that loads (e.g. 'v1.0.0'), but the most reliable way to guarantee query definitions and UI match is to have that version actually published — so publishing the target version, or duplicating the app and publishing the test version there, is the recommended safe path, as is pinning the embed to the currently published release. The described positional-parameter mismatch between a newer release's values and an older release's query template is a legitimate correctness concern worth flagging with a minimal reproduction for engineering review.

Sources

:bookmark: Public app query from draft release version
Solved topic corroborating that queries run via a public/embedded release context resolve against the live version rather than the previewed/draft release's query definition, with staff noting the preview-vs-query-definition gap was filed to engineering.
:bookmark: Built-in URL parameters | Retool Docs
Documents the classic-app _releaseVersion parameter, confirming it controls which app version loads and defaults to the most recent live (published) version — relevant to whether pinning is expected to govern server-side query definitions.

The Community Team is testing out a new automation. Let us know if it's helpful (or not) by leaving a :heart:, :+1:, or :-1:. Or by marking this post as the "Solution"! Let us know if you have any feedback here. :rocket:

3

Update: the issue is specific to embedded sessions

Additional test with the same app, the same pinned release and the same resource:

  • Non-embedded (normal browser session): https://.retool.com/apps/?_releaseVersion=1.7.9 works correctly. The queries execute with the 1.7.9 definitions, and the login query that fails in the embed runs without error.
  • Embedded (external user via POST /api/embed-url/external-user with "releaseVersion": "1.7.9", URL /embedded/authed/?_releaseVersion=…): the frontend shows 1.7.9, but every query request contains "releaseVersion": null and "isEmbedded": true. The server fills the positional queryParams into the query definitions of the published release (1.5.7), which causes the "syntax error at or near AND" described above.

So _releaseVersion is honoured for query execution in normal sessions, but not in embedded/external-user sessions. It looks like the embedded frontend doesn't forward the pinned release in its query requests, or the backend ignores it there.

Related, possibly the same root cause: Public app query from draft release version (public app, draft release, queries from the live release).

Could someone from Retool confirm whether this is a known bug, and whether there is a flag or workaround for embedded apps? Our current workaround is a duplicated app with the test state published.