Send the daily shrink's summaries from a durable queue

.env.example

@@ -102,6 +102,38 @@ HIDE_INACTIVE_ZERO_LENGTH_FROM_TOP=true
 # that deploying mid-day means two shrinks in quick succession: one now, one at midnight for the
 # next date. Deploy just after midnight if you'd rather they stay a full day apart.
 #DAILY_SHRINK_RUN_ON_STARTUP=true
+# How many chats one shrinking statement takes on. It bounds both the rows the statement locks and
+# the ones a failed batch costs, so a /grow sent at midnight waits behind one batch rather than
+# behind every stale dick in the database.
+#DAILY_SHRINK_BATCH_SIZE=100
+
+# The run doesn't send anything: it writes one row per chat into Scheduled_Shrink_Broadcasts, in the
+# same statement that shrinks the dicks, and the worker below sends them (issue #154). So a restart
+# between the shrink and the summary costs nothing, and a broadcast to a few hundred thousand chats
+# can take the hours it needs without holding the next midnight up.
+#DAILY_SHRINK_BROADCAST_POLL_SECONDS=5
+# How many summaries one run claims, and how many of them it sends at once. The concurrency is the
+# knob for throughput — a run gets through that many messages per round trip to Telegram — while the
+# batch size only bounds how much it claims. Keep the concurrency under DATABASE_MAX_CONNECTIONS
+# (every finished summary writes a row) and watch telegram_request_errors_total{kind="rate_limited"}
+# after raising it.
+#DAILY_SHRINK_BROADCAST_BATCH_SIZE=200
+#DAILY_SHRINK_BROADCAST_CONCURRENCY=16
+# How long a claimed batch stays out of every other worker's reach. A worker killed mid-batch leaves
+# its summaries to be claimed again once this runs out, rather than for ever.
+#DAILY_SHRINK_BROADCAST_LEASE_SECONDS=300
+# The first wait after a failure worth retrying; it doubles with each one, up to the cap.
+#DAILY_SHRINK_BROADCAST_RETRY_DELAY_SECONDS=60
+#DAILY_SHRINK_BROADCAST_MAX_RETRY_DELAY_SECONDS=3600
+# Attempts before the row is marked `failed` and left alone.
+#DAILY_SHRINK_BROADCAST_MAX_ATTEMPTS=3
+# How old a summary may get before it stops being worth sending. Yesterday's list of shrinks is
+# still news in a chat that reads once a day; last week's is noise. Only a queue that fell behind
+# can bring one there.
+#DAILY_SHRINK_BROADCAST_MAX_AGE_HOURS=48
+# How many days a finished row is kept before it is cleaned away. 0 keeps them for ever, which is
+# what to set while debugging the worker — and unbounded growth on a busy bot.
+#DAILY_SHRINK_BROADCAST_TABLE_CLEANING_DELAY_DAYS=3
 
 # Perks
 HELP_PUSSIES_COEF=0.01
@@ -201,11 +233,11 @@ DOD_RICH_EXCLUSION_RATIO=0.1
 #MSG_SELFDESTRUCT_RETRY_DELAY_SECONDS=60
 #MSG_SELFDESTRUCT_MAX_RETRY_DELAY_SECONDS=3600
 #MSG_SELFDESTRUCT_MAX_ATTEMPTS=3
-# Every row that is done with is kept this many minutes before a separate cleaning process deletes
+# Every row that is done with is kept this many days before a separate cleaning process deletes
 # it — `removed` (the message is gone), `expired` (it outlived Telegram's 48-hour limit while it
 # waited) or `failed` (every attempt was refused). 0 keeps them for ever, which is useful while
 # debugging the worker itself but grows the table without bound on a busy bot.
-#MSG_SELFDESTRUCT_TABLE_CLEANING_DELAY_MINUTES=1440
+#MSG_SELFDESTRUCT_TABLE_CLEANING_DELAY_DAYS=1
 
 # Announcements are displayed at the end of the Dick of the Day message, not more than a specified
 # amount of times. They (max_shows + per-language texts) are configured in a YAML file — edit