starred/warmbly
1
0
Fork 0
mirror of https://github.com/warmbly/warmbly.git synced 2026-11-02 00:14:22 +00:00
Code Issues Packages Projects Releases Wiki Activity

feat: cut database load from issue 993 with placement, sweep and unibox indexes, redundant index drops, identical-result rewrites of contact facets, dashboard stats, campaign progress, advisor bounces and routing pre-filter, bounded delivery evidence, cold-ramp skip, held advisor sections, ANALYZE after restore and hidden-tab realtime deferral

Browse Source
This commit is contained in:
Matthew Meszaros
2026-10-17 05:18:45 +02:00
parent 0911c5390b
commit ae9eca5c7e
52 changed files with 1102 additions and 149 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/content/docs/development/configuration.mdx
+2
View File
@@ -687,6 +687,8 @@ Per-mailbox `test_mode`, `test_send_enabled` and `test_receive_enabled` separate
|---|---|---|
| `TASKS_PROVIDER` | `local` (an in-process Postgres poller) or `gcloud` (Cloud Tasks) | `local` |
| `TASKS_LOCAL_POLL_INTERVAL` | How often the local poller looks for due work | `1s` |
| `SEND_PLAN_SNAPSHOT_INTERVAL` | How often the backend re-walks the send plan of every active campaign whose stored plan is out of date. Each walk reads all of that campaign's leads, so a longer interval lowers database load on large campaigns | `1m` |
| `SEND_PLAN_SNAPSHOT_MAX_AGE` | How old a stored send plan may be before it counts as out of date. An out-of-date plan is still served, with `stale: true`, while a fresh one is computed in the background | three times `SEND_PLAN_SNAPSHOT_INTERVAL` (`3m`) |
| `BILLING_PROVIDER` | `none` (every feature unlocked, no trial expiry; the dashboard reports the workspace as self-hosted rather than on a free tier and hides billing) or `stripe` | `none` |
| `STRIPE_SECRET_KEY`, `STRIPE_WEBHOOK_SECRET`, `STRIPE_PUBLISHABLE_KEY` | Required together when `BILLING_PROVIDER=stripe`. The backend exits at boot if any is missing | unset |
docs/content/docs/development/data-control.mdx
+1 -1
View File
@@ -222,7 +222,7 @@ docker compose -p warmbly exec backend warmblyctl restore --file /data/blobs/war
docker compose -p warmbly restart
```
The restore empties the schema and replays the dump, so it replaces everything currently on that instance and asks you to type `restore` first.
The restore empties the schema and replays the dump, so it replaces everything currently on that instance and asks you to type `restore` first. It then runs `ANALYZE`, since a dump carries no planner statistics; a failure there only warns.
Before it does anything it compares the bundle's `CREDENTIALS_ENCRYPTION_KEY` and `KMS_LOCAL_MASTER_KEY` against the destination's and refuses to continue when they differ, printing the two lines to put in `.env`. That check is the point of the command: without it a restore looks like it worked and every mailbox fails to authenticate days later, with no error that names the cause.
docs/content/docs/development/warmblyctl.mdx
+2
View File
@@ -499,6 +499,8 @@ Before anything is written it compares the bundle's `CREDENTIALS_ENCRYPTION_KEY`
Blobs are unpacked over the blob root additively: files the bundle knows about are overwritten, anything else is left alone.
Once the dump has loaded, the restore runs `ANALYZE`, because a dump carries no planner statistics. If that step fails the restore still completes and prints a warning; run `ANALYZE` in `psql` yourself afterwards.
[Data control](/development/data-control/#moving-an-instance) walks the whole move to a new host.
## org list