Skip to content

Stop For You VF from skipping Phoenix reply parents - #62

Closed
Pitchfork-and-Torch wants to merge 19 commits into
mainfrom
cursor/magellan-reply-parent-vf-cad1
Closed

Stop For You VF from skipping Phoenix reply parents#62
Pitchfork-and-Torch wants to merge 19 commits into
mainfrom
cursor/magellan-reply-parent-vf-cad1

Conversation

@Pitchfork-and-Torch

Copy link
Copy Markdown
Owner

Bug

Phoenix retrieval, MOE, Topics, and TweetMixer set in_reply_to_tweet_id and leave ancestors empty. Thunder and Latest Following copy the parent into ancestors.

VFCandidateHydrator only fetches candidate.ancestors as ancillary ids. should_drop_ancillary only walks that list. A mute or block on the parent tweet never reaches AncillaryVFFilter, so the reply still ranks on For You.

This is not conversation-gap expansion (xai-org#97). Not mixer ancestor_users mute/block (xai-org#101 / xai-org#111). Not quote/RT handle mute-keyword (xai-org#140 / xai-org#164). Not civic followee quotes (xai-org#178).

Fix

When ancestors is empty, treat in_reply_to_tweet_id as the reply parent for VF fetch and ancillary drop. Thunder's existing ancestor list is unchanged.

Proof

  • Entry: PhoenixSource / PhoenixMOESource / PhoenixTopicsSource / TweetMixerSource write in_reply_to_tweet_id and leave ancestors empty
  • Sink: VFCandidateHydrator oon_ids + should_drop_ancillary + AncillaryVFFilter
  • Break: ancillary VF walked ancestors only; OON Phoenix replies never populated that list
  • Viewer effect: reply to a muted or blocked parent still serves on For You
  • Twin: ThunderSource and Following Night Owl already push in_reply_to into ancestors

Tests

  • reply_ancestor_ids_uses_in_reply_to_when_ancestors_empty
  • reply_ancestor_ids_keeps_thunder_ancestors
  • phoenix_reply_drops_when_parent_author_is_muted
  • phoenix_reply_drops_when_parent_author_blocked_viewer
  • phoenix_reply_keeps_when_parent_is_allowed
  • thunder_ancestors_still_drop_and_do_not_use_a_stale_in_reply_to
  • unit tests added; cargo test cannot run in the public dump (no home-mixer Cargo.toml)
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
Phoenix retrieval, MOE, Topics, and TweetMixer set in_reply_to_tweet_id
but leave ancestors empty. Ancillary VF only fetched candidate.ancestors,
so a mute or block on the parent never dropped the reply. Thunder already
copies the parent into ancestors.

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

Copy link
Copy Markdown
Owner Author

wrong tree: upstream already at xai-org#180. Close fork twin; do not squash-merge.

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