Skip to content

Commit f846ed7

Browse files
waleedlatif1claude
andcommitted
docs(data-drains): describe the resolved feature, not the bare flag
Two things were wrong in the self-hosted flag paragraph. The first sentence attributed the page and the endpoints to `DATA_DRAINS_ENABLED` alone, which the next sentence then contradicted. `enterpriseFeatureEnabled` resolves `explicit ?? (ENTERPRISE_ENABLED || legacy default)`, and the legacy default for data drains is `false` — so the feature is on with the variable unset whenever `ENTERPRISE_ENABLED` is set, and an explicit `false` always wins. The paragraph now leads with that resolution. The rationale given for the public twin was also wrong. Inside a workspace `WorkspaceHostProvider` seeds the deployment shape from the server-resolved host context, `useDeploymentShape()` returns that seeded value, and the settings sidebar gates `data-drains` on `features.dataDrains` from it — so the page follows the server regardless of the twin, and "set it so the browser matches the server" misdescribed what the browser reads. The twin still backs `browserFallbackShape()` where nothing has seeded the shape, and it is what `sim-setup doctor` compares, so the advice to set it stands with the real reason. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 parent 2cbf615 commit f846ed7

1 file changed

Lines changed: 3 additions & 1 deletion

File tree

apps/docs/content/docs/platform/enterprise/data-drains.mdx

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -237,7 +237,9 @@ DATA_DRAINS_ENABLED=true
237237
NEXT_PUBLIC_DATA_DRAINS_ENABLED=true
238238
```
239239

240-
`DATA_DRAINS_ENABLED` shows the **Settings → Organization → Data drains** page and gates the server-side mutating endpoints and the cron dispatcher. When the feature resolves off on a self-hosted deployment — neither it nor `ENTERPRISE_ENABLED` is set, or it is set to `false` — the page is hidden, drain create/update/delete/run requests return `404`, and the dispatcher is a no-op. Set `NEXT_PUBLIC_DATA_DRAINS_ENABLED` to the same value so the browser's configuration matches the server's; on a Compose install or source checkout, `npx sim-setup doctor` reports the pair disagreeing.
240+
On a self-hosted deployment the feature resolves on when `DATA_DRAINS_ENABLED` is `true`, or when it is unset and `ENTERPRISE_ENABLED` is set; an explicit `false` always wins. That resolved value — not the bare variable — gates the **Settings → Organization → Data drains** page, the server-side mutating endpoints, and the cron dispatcher. When it resolves off the page is hidden, drain create/update/delete/run requests return `404`, and the dispatcher is a no-op.
241+
242+
Inside a workspace the browser reads that resolved value from the server, so the page follows the server whether or not `NEXT_PUBLIC_DATA_DRAINS_ENABLED` is set. Set it to the same value anyway: it backs the client fallback on surfaces rendered outside a workspace, and on a Compose install or source checkout `npx sim-setup doctor` reports the pair disagreeing.
241243

242244
### Scheduling the dispatcher
243245

0 commit comments

Comments
 (0)