[waleedlatif1]

Summary

• Follow-up to fix(errors): actionable table read timeouts, 409 for duplicate custom tools, Instagram revocation, selector failure logs #9880.
• Selector provider failure logs now redact any path segment that holds an email address (@ or %40). A Google Calendar id is usually its owner's address, so a failed calendar lookup was writing that address into WARN logs. Query strings and OData (...) path arguments were already stripped.
• Corrected the TABLE_QUERY_TIMEOUT TSDoc. It claimed a retry "only times out again", but a sort or range filter on a stored column is cache-bound: the same query can finish in well under a second warm and still exceed the 15s guard cold. The doc now says why it's a 400.

Type of Change

• Bug fix

Testing

• New http.test.ts case: a failed provider call logs the endpoint without the query string, the search text, or an email path segment. Shown red with the email redaction removed.
• Ran the selector and table application suites (321 passed), biome check, check:comment-hygiene, check:utils and check:explicit-any. The pre-push lint:check and type-check pass.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing (new tests pass the test-audit authoring gate)
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
docs	Skipped		Nov 11, 2026 10:50pm UTC

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge.

Summary

Redacts email-bearing path segments from selector provider failure logs and clarifies table timeout guidance.

• Failed selector logs hide email addresses in provider paths.
• Table timeout notes explain why cached rows change query speed.

_{Reviews (2) · Last reviewed commit: "fix(table): keep timeout guidance to sor..." · Reviewed by Greptile}

[cubic-dev-ai]

1 issue found across 3 files

Confidence score: 4/5

• The count guidance in rows.ts suggests sorting by createdAt and keeping fewer rows, but the count endpoint supports neither, so callers may chase fixes that cannot help. Give count callers separate, accurate guidance.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/sim/lib/table/application/rows.ts">

<violation number="1" location="apps/sim/lib/table/application/rows.ts:519">
P2: The new count wording still recommends `Sort by createdAt` and `keep fewer rows`, but the public count endpoint cannot sort and its fixed page limit does not reduce the full-view `COUNT(*)`. Give count callers separate guidance, such as narrowing to a selective equality predicate, instead of presenting row-query remedies as fixes.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Turn on auto-fix | Re-trigger cubic</sub>

[waleedlatif1]

@greptile

[waleedlatif1]

@cubic-dev-ai review this PR

[cubic-dev-ai]

@cubic-dev-ai review this PR

@waleedlatif1 I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

No issues found across 3 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Turn on auto-fix | Re-trigger cubic}