bvandeusenandClaude Opus 5
1e45e2c56c
CI / extension-version (push) Successful in 3s
CI / lint (push) Successful in 3s
Build images / sign-extension (push) Successful in 4s
Build images / build-agent (push) Successful in 7s
CI / frontend-build (push) Successful in 22s
CI / backend-lint-and-test (push) Successful in 31s
Build images / build-web (push) Successful in 1m6s
Build images / smoke-web (push) Skipped
Build images / build-ml (push) Successful in 1m59s
Build images / promote (push) Skipped
CI / integration (push) Failing after 2m7s
A synthetic post is no longer sealed at creation. A creator who adds two more variants the next day extends the existing post, its body grows with the new messages, and no rival post appears. That is what makes chat capture read as content trickling in rather than as a stream of separate arrivals. The sweep now runs two passes per source and the ORDER is load-bearing: offer new messages to still-open groups BEFORE founding new ones, because whichever runs first claims a message. E3's three named problems, each answered rather than discovered later: **Bridging.** A candidate near two groups joins NEITHER. Nearest-wins would silently make an arbitrary choice between two posts the operator may already have seen; merging them is worse still, because a merge rewrites history and anything pointing at the absorbed post dangles. Leaving it to found its own group is the recoverable failure. AMBIGUITY_MARGIN is a module constant and deliberately not a setting — it is not a quality dial anyone would tune toward a better feed, and exposing it would invite turning it to zero, which is exactly the silent arbitrary choice it prevents. **Re-surfacing without thrashing.** A grouping has two dates, and which one orders the feed is a real decision, so the feed orders by neither directly. Ordering by when the drop STARTED buries a group that grows a week later under a week of other posts — defeating the point of keeping it open. Ordering by every growth lets a group gaining one image a day live permanently at the top, so chat out-competes authored posts for the front page — the opposite of "post pacing stays front and centre". Instead `resurfaced_at` moves only when growth clears BOTH a minimum-images bar and a cooldown, so a drip-feed updates in place and a genuine second wave resurfaces exactly once. It is NULL on every ordinary post, so the sort key COALESCEs through it without moving anything that is not a grouping. **Reopening forever.** Groups close after a quiet period — artists reuse characters for years, and a group left open indefinitely will eventually absorb something it shouldn't. Openness is DERIVED, not stored: a group is open if it grew (or started) within the window. Lowering the setting closes old groups and raising it reopens them, with nothing to repair either way; a stored closed_at would have needed a sweep to set it and a repair path to ever change the policy. Rule 89 is satisfied structurally rather than by a parallel mechanism: celery_signals writes a TaskRun for every task, which already supplies duration, the 5-minute stalled-run recovery, and retention pruning. What this step owed on top of that was a wall-clock limit (present) and idempotence — re-running the joiner adds nothing, asserted directly rather than left to the unique (image, post) constraint to catch. Two bugs fixed in the writing, one of which my own test would have hit: * `assign_to_group` sorted bare (distance, Post) tuples, which falls through to comparing Posts when two distances tie — and a perfectly symmetric bridge, the exact case the function exists for, would have raised TypeError instead of declining to choose. Now keyed on the distance alone. * The cursor was still built from `post_date or downloaded_at` while the ORDER BY had gained `resurfaced_at`. Two expressions that disagree at a page boundary don't error, they silently skip or repeat rows; both sites now go through one `_post_sort_value`, and a test pages through one row at a time to prove the walk matches the whole list. Image linking is now one shared helper rather than written twice, because creation and joining would otherwise be free to drift on exactly the detail (which post owns the image) that makes a grouping reversible. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LNXXULQDjVZmbuNa2G9mD9
87 lines
3.2 KiB
Python
87 lines
3.2 KiB
Python
"""An open grouping — a synthetic post that a later drop can still join.
|
|
|
|
Milestone 388, step E3. E2's synthetic post was sealed at creation: a creator
|
|
who added two more variants the next day started a second post. These two
|
|
columns let the group stay open and absorb the follow-up, without the post
|
|
either freezing or thrashing the feed.
|
|
|
|
## Why openness is derived rather than stored
|
|
|
|
There is no `closed_at` here on purpose. A group is open if it grew (or
|
|
started) within `ml_settings.discord_group_close_after_hours`, so openness is a
|
|
comparison rather than a state — which means lowering the setting closes old
|
|
groups and raising it reopens them, with nothing to repair either way. A stored
|
|
flag would need its own sweep to set it and its own repair path to ever change
|
|
the policy, for no gain.
|
|
|
|
## Why `resurfaced_at` is separate from `last_grew_at`
|
|
|
|
They answer different questions. `last_grew_at` is when the group last
|
|
absorbed something — it decides how long the group stays joinable and is what
|
|
the card shows. `resurfaced_at` is the FEED POSITION, advanced only when the
|
|
anti-thrash rule fires, so a group that gains one image a day updates in place
|
|
while a genuine second wave moves once. Folding them together would make every
|
|
addition a bump, which is the annoyance this step exists to avoid.
|
|
|
|
Both are NULL on every ordinary post, so the feed's sort key can COALESCE
|
|
through `resurfaced_at` without moving anything that is not a grouping.
|
|
|
|
Revision ID: 0093
|
|
Revises: 0092
|
|
Create Date: 2026-09-10
|
|
|
|
"""
|
|
from typing import Sequence, Union
|
|
|
|
import sqlalchemy as sa
|
|
from alembic import op
|
|
|
|
revision: str = "0093"
|
|
down_revision: Union[str, None] = "0092"
|
|
branch_labels: Union[str, Sequence[str], None] = None
|
|
depends_on: Union[str, Sequence[str], None] = None
|
|
|
|
|
|
def upgrade() -> None:
|
|
op.add_column(
|
|
"post", sa.Column("last_grew_at", sa.DateTime(timezone=True), nullable=True),
|
|
)
|
|
op.add_column(
|
|
"post", sa.Column("resurfaced_at", sa.DateTime(timezone=True), nullable=True),
|
|
)
|
|
# No index on either. The feed already sorts on an unindexed
|
|
# COALESCE(post_date, downloaded_at) expression, so adding resurfaced_at to
|
|
# that COALESCE changes nothing about how the query plans — and inventing a
|
|
# functional index here would be guessing at the fix for a cost nobody has
|
|
# measured. Measuring it is step B2's job.
|
|
|
|
op.add_column(
|
|
"ml_settings",
|
|
sa.Column(
|
|
"discord_group_close_after_hours", sa.Float(),
|
|
server_default=sa.text("168"), nullable=False,
|
|
),
|
|
)
|
|
op.add_column(
|
|
"ml_settings",
|
|
sa.Column(
|
|
"discord_group_resurface_min_images", sa.Integer(),
|
|
server_default="2", nullable=False,
|
|
),
|
|
)
|
|
op.add_column(
|
|
"ml_settings",
|
|
sa.Column(
|
|
"discord_group_resurface_cooldown_hours", sa.Float(),
|
|
server_default=sa.text("24"), nullable=False,
|
|
),
|
|
)
|
|
|
|
|
|
def downgrade() -> None:
|
|
op.drop_column("ml_settings", "discord_group_resurface_cooldown_hours")
|
|
op.drop_column("ml_settings", "discord_group_resurface_min_images")
|
|
op.drop_column("ml_settings", "discord_group_close_after_hours")
|
|
op.drop_column("post", "resurfaced_at")
|
|
op.drop_column("post", "last_grew_at")
|