Skip to content

Stop user-cred from counting reverse linked-account edges - #46

Closed
Pitchfork-and-Torch wants to merge 19 commits into
mainfrom
cursor/user-cred-linked-edges-21ef
Closed

Stop user-cred from counting reverse linked-account edges#46
Pitchfork-and-Torch wants to merge 19 commits into
mainfrom
cursor/user-cred-linked-edges-21ef

Conversation

@Pitchfork-and-Torch

Copy link
Copy Markdown
Owner

Bug

filterLinkedUserEdges exists to keep linked-account pairs out of UserCred PageRank. It joined follow and engagement edges on the exact ordered pair (userId, linkedUserId) from AccountExpansionInvestigations.

That dataset is an undirected investigation pair, not a graph edge. Flock follows and 7-day fav/RT edges are oriented the other way: follower→followee, engager→author. Mass flows that same direction.

Proof

  1. Investigations row is (mainId, altId).
  2. Alt follows / likes / RTs main → edge (altId, mainId).
  3. Join key (altId, mainId)(mainId, altId) → edge kept.
  4. PageRank pushes mass follower→followee, so alts pump the primary.
  5. Published score feeds isHighPageRankV2 / cred.score. Abuse enforcement skips on cred.is_high || cred.score >= 50. Safety-label user-agg excludes high page-rank users from NSFW account labels.

Main→alt was the only direction dropped — the one that does not inflate the primary.

Fix

Emit both orders of each linked pair (skip self-pairs). filterLinkedUserEdges is unchanged. If the snapshot already stores both directions, the extra keys are a no-op.

One file: user-cred-v2/UserCredV2App.scala.

Not a home-mixer / VF / Thunder change. Not a fork PR.

Open in Web Open in Cursor 

CI agent and others added 19 commits August 14, 2026 20:55
in_network_ids is passed to the VF client without deduplication, while
oon_ids is deduped four lines below. retweeted_tweet_id is pushed for
every candidate that has one, so the same ID repeats once per retweet of
a given post — most often when that post is going viral.

Neither VfClient implementation dedupes its input: StratoVfClient builds
one call per element, and XaiVfClient chunks by XAI_VF_MAX_BATCH_SIZE, so
duplicates consume batch slots and can force an extra round trip.

Not a correctness issue — results collapse into a HashMap keyed by tweet
ID — but redundant work on the For You serving path.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Deduplicate in_network_ids before VF lookup
Account-expansion pairs are undirected. Matching only
(userId, linkedUserId) left alt→main follows and engagements in
the PageRank graph, so linked alts could still pump mass into
the primary account.

Co-authored-by: Jon Bailey <Pitchfork-and-Torch@users.noreply.github.com>
@Pitchfork-and-Torch

Copy link
Copy Markdown
Owner Author

Wrong base (fork). Closed. Upstream PR: xai-org#165

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants