fix(follow-gate): re-check a failed follow before rejecting, and record rejections - #73
Open
valentinpanizza wants to merge 2 commits into
Open
valentinpanizza wants to merge 2 commits into
valentinpanizza wants to merge 2 commits into
Conversation
…rd rejections Instagram does not report a brand-new follow immediately, and the gate asks people to follow and then tap a button sitting right in front of them — so tapping seconds after following is the normal case. Rejecting on the first false therefore turns away the exact people who did what was asked, and tells them to follow an account they already follow. Worse, the message they get back is the same prompt verbatim, so from their side the bot simply stopped responding. Several users on my instance tapped repeatedly (1.6 taps per person) trying to get a reaction. On the first false the tap is now re-queued with a delay instead of being rejected: if the follow has registered by then the link goes out on its own, with nothing more for the person to do. The job id is deterministic so repeated taps collapse into the one pending re-check rather than queueing a re-check each. FOLLOW_RECHECK_DELAY_MS (default 60s) tunes the wait. Only a second false rejects, and that now writes an OperationalEvent. The branch previously returned without recording anything, so a gate turning people away left no trace at all — its rejection rate could not be measured, only inferred from users complaining.
|
@valentinpanizza is attempting to deploy a commit to the diwenne's projects Team on Vercel. A member of the Team first needs to authorize it. |
…ked again The re-check was queued with a fixed id per automation and user. BullMQ keeps completed jobs (removeOnComplete: count 1000) and silently drops an add whose id is still retained, so once someone had been re-checked, every later re-check for them vanished: their next false tap produced no link and no prompt, and nothing was logged. Caught testing a second tap on the same account. Bucket the id by the recheck window instead. A burst of taps still collapses into a single re-check, which is what the fixed id was for, but a tap in a later window gets a fresh id that no retained job can block. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This branch has not been deployed
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
1 participant
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.
What happens
Someone taps the follow-gate button, and the conversation goes quiet. On my
instance people tapped 1.6 times each on average, trying to get a reaction.
Root cause
is_user_follow_businessdoes not report a brand-new follow right away, and thegate asks people to follow and then tap a button that is sitting in front of
them — so tapping seconds after following is the normal case, not an edge one.
Rejecting on the first
falsetherefore turns away the exact people who did whatwas asked, and the message they get back is the same prompt verbatim, telling
them to follow an account they already follow. From their side the bot just
stopped responding.
The branch also returned without writing anything, so a gate turning people away
left no trace at all. Its rejection rate could not be measured — only inferred
from users complaining.
The fix
On the first
falsethe tap is re-queued with a delay instead of rejected. Ifthe follow has registered by then, the link goes out on its own with nothing more
for the person to do. The job id is deterministic, so repeated taps collapse into
the one pending re-check rather than queueing a re-check each — important, since
repeated tapping is the symptom.
FOLLOW_RECHECK_DELAY_MS(default 60s) tunes the wait. Only a secondfalserejects, and that now writes an
OperationalEventso the rate is visible.Trade-off
The delay is paid only by taps that fail the first check — under this diagnosis,
the people the gate is currently losing. Anyone who already followed still gets
their link immediately.