You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: address the review findings raised on the v0.8.21 release PR
Eight of the thirteen threads were real. Each was verified against source
before changing anything; three were pushed back on and are unchanged.
Knowledge and credential groups:
- The connector Access field resolved its provider through the standard-OAuth
subset, which excludes Slack — Slack collects accounts through a custom bot.
The field never rendered for a Slack connector, so it could not enter members
mode and, worse, a per-member Slack connector had no way back to workspace
mode. Resolved across all credential-group providers instead.
- The v1 document delete looked the document up with an ACL scope and then ran
an unscoped delete. The access-aware path already existed and v2 already used
it; v1 was the last surface on the old one. The window is small and not
attacker-controllable, but the divergence is worth closing.
- Enrollment surfaced `CredentialGroupEnrollmentError` as a bare 500. A missing,
disabled, or unconfigured credential group is the admin's to act on, so the
policy now projects its 404/409 the way the credential-group routes do.
- The workspace-level member-connector listing used knowledge-base
concealment and answered "Knowledge base not found" where its siblings return
an authorization response. It names a workspace, not a base, so it now uses an
unconcealed policy — the convention the policy file already documents.
Home:
- Restoring a queued Build message left the search query in the URL, and the
rule that forces Search whenever a query is present flipped the composer
straight back. The edit was discarded and the original message dispatched.
Clearing the query alongside the mode restore batches into the same nuqs
update, so the forcing rule never observes the intermediate state.
Docs and tooling:
- `redis.mdx` claimed completed work is unaffected by losing Redis. Webhook
idempotency markers live wherever the cache does, with a 7-day TTL sized to
the longest provider retry window, and the bundled Redis runs without
persistence — so a redelivery after a restart can re-run a finished workflow
with its real side effects. Billing, checkout, and Chat-send idempotency are
pinned to PostgreSQL. Corrected the same claim in the chart's values.
- `/ship` Phase A never regenerated the docs manifest that Phase B hard-gates
on, so adding or renaming a docs page aborted the command.
- The CLI updater prints a yarn command, but the upgrade tabs offered none.
- Documented that Ask may reach an integration for an explicitly requested
action, not only when sources cannot answer.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015BwsJTEQRzWJaY4BRCkPZt
Copy file name to clipboardExpand all lines: apps/docs/content/docs/platform/self-hosting/redis.mdx
+3-1Lines changed: 3 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -24,7 +24,9 @@ Sim uses Redis as a message bus and shared cache. Both deployments ship it by de
24
24
With more than one app or realtime replica and no `REDIS_URL`, users on different pods stop seeing each other's edits and live status updates. Beyond one startup log line noting single-pod mode, nothing is logged — the app looks healthy and quietly loses events. Treat Redis as mandatory the moment `replicaCount` exceeds 1.
25
25
</Callout>
26
26
27
-
Everything Sim keeps in Redis is cache, coordination state, or an in-flight event — never committed data, which lives in PostgreSQL and object storage. Persistence is therefore not required. Losing or restarting the instance is not free, though: cancellation markers and the cross-pod half of execution streaming live here, so active runs stop streaming and a cancellation issued across the gap may not land. Completed work is unaffected.
27
+
Everything Sim keeps in Redis is cache, coordination state, or an in-flight event — never committed data, which lives in PostgreSQL and object storage. Losing or restarting the instance costs active runs their streaming, and a cancellation issued across the gap may not land.
28
+
29
+
It also costs webhook deduplication. Webhook idempotency markers live wherever the cache does, with a 7-day TTL sized to the longest provider retry window, so a redelivery arriving after a restart can re-run a workflow that already completed — with its real side effects. Billing, checkout, and Chat-send idempotency are pinned to PostgreSQL and are never at risk. The bundled Redis runs without persistence, which is fine for coordination state; if duplicate webhook side effects would be unacceptable for your deployment, point `REDIS_URL` at a managed instance with persistence enabled.
0 commit comments