Email Security: a campaign takes two messages, and member_count never goes down - #381
Merged
Conversation
… goes down The engine creates a campaign on the SECOND message and shows nothing below that, so the docs should say both plainly: a cluster of one is not in the campaign list, not in the Overview count and not fetchable by id, and min_members cannot be lowered past two. Also states what member_count is, which the sweep-preview section already leaned on without defining: the historical spread of the attack, not a count of messages still in the 35-day index, and never decremented.
Contributor
Author
|
/lc-review |
lcbill
approved these changes
Sep 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Documents two campaign semantics the product enforces and the docs did not state.
A campaign is created on the second message. The engine has always intended this ("a campaign of one is not a campaign"), but 70% of the campaigns on the acceptance org had exactly one member because of two backend defects. Those are fixed, and the read side now enforces a two-member floor: a sub-threshold cluster is absent from the campaign list, from the Overview's active-campaign count and from the campaign detail, and
min_memberscan only narrow past two rather than below it. That is a visible behaviour change for an API client that was passingmin_members=1, so it is stated in both the guide and the route table.member_countnever decreases. The sweep-preview section already leaned on the number without defining it. A campaign row lives 400 days while the message index lives 35, so the count is the historical spread of the attack rather than a count of messages still in the index — a campaign whose members have aged out still says how big the attack was.Public repo: PR only, not merged.