SeaTable Cloud: linked formula predicates disagree between native UI and SQL

User Talk Formulas
1

Hello SeaTable support,

We use cloud.seatable.io and have found a discrepancy with synthetic test rows only. No customer data is involved.

A Configuration row has Status=Active, Availability=Available, InventoryStatus=Made to Order, MissingRequiredData empty and ReadyForShopify=true in a direct row read. A Component links to this single Configuration.

Its original readiness formula is:
and({Status}=“Active”,{_ValidationErrors}=“”,countlinks(“Configuration”,“{ReadyForShopify}=true()”)=1)

This feeds Bundle readiness and then a Listing lookup. The native linked Listing can report false even while the Bundle’s own native row reports true. Direct row and SQL reads also disagree.

We isolated four predicates on the same Component, keeping all data and links unchanged:

  1. and({Status}=‘Active’,{Availability}=‘Available’,or({InventoryStatus}=‘In Stock’,{InventoryStatus}=‘Made to Order’))
  2. and({MissingRequiredData}=‘’,{Status}=‘Active’,{Availability}=‘Available’)
  3. and({MissingRequiredData}=‘’,{InventoryStatus}=‘Made to Order’)
  4. and({MissingRequiredData}=‘’,{Status}=‘Active’,{Availability}=‘Available’,{InventoryStatus}=‘Made to Order’)

Each countlinks predicate produced native Listing Ready=true and lookup=true, but the simultaneous SQL read returned Ready=false and lookup=[false]. Restoring the original formula restored the native false result. Exact saved source was verified after each trial; no row values or links were changed.

Could you explain which read route is authoritative, whether linked computed predicates have a current Cloud evaluation/caching limitation, and how to obtain consistent results in the UI, row API and SQL? Please provide a supported reproducible correction, including any current Cloud depth constraints if relevant. We cannot remove business validation or replace readiness with a constant.

We can provide a minimal synthetic reproduction on request. Please do not request credentials or API keys by email.

Thank you.

2

Hi!

Can you please provide a minimal reproducible example?
This should include the required column types/definitions.

Thank you!

EDIT: In addition, please provide the full SQL query that (apparently) returns incorrect results.

3

Thanks for asking for the column definitions and full SQL. I rechecked the original case without changing any formulas, input values, links, or statuses.

The affected synthetic chain is Configuration 201/202 → Component 320/321 → Bundle 300 → Listing 401. For Listing 401, the native grid reports ReadyForShopify=false, MissingRequiredData="Unready Bundle target; ", and _BundleReadyLookup=false. The native Ready for Shopify view excludes it. The row-list API and the full SELECT below return true, an empty MissingRequiredData, and [true].

SELECT `ListingID`, `ListingCode`, `PublicationStatus`, `ReadyForShopify`,
       `MissingRequiredData`, `_BundleReadyLookup`
FROM `11_ShopifyListings`
WHERE `ListingID` = 'a6100916-2026-4000-8000-000000000401';

Relevant column types and definitions:

  • Component.Configuration: single link to 10_SellableConfigurations.
  • Component.Status: single select.
  • Component._ValidationErrors: text-result formula.
  • Component._ReadyComponent: boolean-result formula:
and({Status}="Active",{_ValidationErrors}="",countlinks("Configuration","{ReadyForShopify}=true()")=1)
  • Configuration.ReadyForShopify: boolean-result formula:
and({MissingRequiredData}="",{Availability}="Available",{Status}="Active",or({InventoryStatus}="In Stock",{InventoryStatus}="Made to Order"))
  • Bundle.ReadyForShopify: boolean-result formula:
and({Status}="Active",{MissingRequiredData}="",{Availability}="Available",or({InventoryStatus}="In Stock",{InventoryStatus}="Made to Order"))
  • Listing.Bundle: single link to 12_Bundles.
  • Listing._BundleReadyLookup: native link-formula lookup of Bundle.ReadyForShopify, array of booleans, no conditions, deduplication disabled.
  • Listing.ReadyForShopify: boolean-result formula:
and({MissingRequiredData}="",or({PublicationStatus}="Draft",{PublicationStatus}="Ready",{PublicationStatus}="Published"))

The longer validation formulas and their transitive definitions are in the linked synthetic dependency candidate: 32 rows, 205 columns across 15 tables, with a harmless test image. It contains no business records, account identifiers, working-base URLs, credentials, or access tokens. It is a dependency extract, NOT yet a confirmed minimal reproducer: it has not been restored into a clean base. This distinction matters because reducing the dependency chain may hide the issue.

Could you advise which dependency pattern should be reduced first, and whether this current UI/API/SQL discrepancy indicates a supported formula-depth or cache limitation? We need a supported correction that preserves the positive and negative validation cases and produces consistent results across read routes. We cannot replace computed readiness with a constant or remove business validation to obtain a passing value.

Synthetic dependency candidate (ZIP, 12 KB; read-only download): SeaTable_Readiness_Synthetic_Candidate_2026-09-29.zip

The forum accepts image attachments only, so the ZIP is provided through the read-only link above.

4

Can you please either upload a DTABLE export of the base or send us an invite link (either via private message or to support@seatable.com?

The ZIP file you linked only includes the JSON column definitions which cannot be imported directly.

Thank you!

7

Thank you for providing the dtable file via email. I have replied to you.

In case someone else is running into similar issues:

The discrepancy is caused by different limits between server- and client-side formula evaluation.
In this case, the server-side evaluation is correct.

On the client side, the formula evaluation engine currently stops recomputing linked formulas after 5 link hops. This limit is in place to ensure optimal performance when loading bases and navigating inside the UI.

Unfortunately, this limit currently causes a “silent error” and does not indicate that a cell value could not be computed due to the complexity of the formula(s). I have created a ticket inside our internal issue tracker regarding this.

Sorry for the inconvenience that this may have caused!

However, we do not plan on increasing the limit of 5 link hops for the reasons mentioned above.