Skip to main content

Overview

Filters remove unwanted candidates from the pipeline. They run sequentially after candidate hydration, allowing each filter to see the results of previous filters. Filters partition candidates into “kept” and “removed” sets.

Filter Trait

The Filter trait defines the interface for filtering candidates:
candidate-pipeline/filter.rs
fn(&self, &Q) -> bool
Optional gating logic to conditionally enable/disable the filter based on query parameters
async fn(&self, &Q, Vec<C>) -> Result<FilterResult<C>, String>
The main filtering method. Partitions candidates into kept and removed sets.
fn(&self) -> &'static str
Returns the filter name for logging and metrics. Auto-generated from the type name by default.

Age Filter

The Age filter removes tweets older than a specified duration:
home-mixer/filters/age_filter.rs
The Age filter uses Twitter’s Snowflake ID format to extract the creation timestamp from the tweet ID itself, without requiring external service calls.

Self Tweet Filter

The Self Tweet filter removes tweets where the author is the viewer:
home-mixer/filters/self_tweet_filter.rs
This filter prevents users from seeing their own tweets in their For You feed, which improves content diversity.

Author Socialgraph Filter

The Author Socialgraph filter removes candidates from blocked or muted authors:
home-mixer/filters/author_socialgraph_filter.rs
This filter respects user privacy preferences by removing content from blocked and muted authors. This is a critical safety and UX feature.

Visibility Filtering (VF) Filter

The VF filter applies visibility filtering rules based on safety results:
home-mixer/filters/vf_filter.rs
The VF filter applies content safety policies by removing tweets that violate safety rules. This relies on the visibility_reason field being hydrated earlier in the pipeline.

Available Filters

The home-mixer service includes these filters:

AgeFilter

Removes tweets older than a specified duration

AuthorSocialgraphFilter

Removes tweets from blocked or muted authors

CoreDataHydrationFilter

Removes tweets missing core data

DedupConversationFilter

Removes duplicate conversation threads

DropDuplicatesFilter

Removes exact duplicate tweets

IneligibleSubscriptionFilter

Removes subscription content for non-subscribers

MutedKeywordFilter

Removes tweets matching muted keywords

PreviouslySeenPostsFilter

Removes tweets the user has already seen

PreviouslyServedPostsFilter

Removes tweets already served in recent requests

RetweetDeduplicationFilter

Deduplicates retweets of the same original tweet

SelfTweetFilter

Removes the user’s own tweets

VFFilter

Applies visibility filtering safety rules

Sequential Execution

Filters run sequentially, allowing each filter to see the results of previous filters:
candidate-pipeline/candidate_pipeline.rs
If a filter fails, the error is logged and the original candidate list is restored. This ensures filter failures don’t accidentally remove valid candidates.

Filter Stages

Filters can run at two points in the pipeline:
1

Pre-Selection Filtering

Runs after candidate hydration, before scoring. Used for removing invalid or unwanted candidates.
2

Post-Selection Filtering

Runs after selection, on candidates that will be returned. Used for final safety checks.

Error Handling

If a filter fails, the original candidate list is restored (no filtering occurs). This “safe” error handling prevents bugs in one filter from accidentally removing all candidates.

Best Practices

Use Rust’s partition method for clean, functional filtering:
Short-circuit when filtering isn’t needed:
Include meaningful context in error messages:
Use the stats macro for automatic metrics:

Partition Example

The partition pattern is idiomatic Rust for filtering:

Performance Considerations

Filters run sequentially and process all candidates, so keep filter logic fast. For expensive operations (like external service calls), hydrate the data earlier in the pipeline and filter based on hydrated fields.

Conditional Enabling

Filters can be conditionally enabled based on query parameters:
This allows dynamic filter selection based on:
  • User experiments/flags
  • Query parameters
  • A/B test assignments
  • Feature flags

Pipeline Framework

Understand the overall pipeline execution flow

Hydrators

Hydrate features used by filters

Scorers

Score candidates after filtering

Visibility Filtering

Learn about content safety policies