Skip to main content

Overview

Hydrators enrich candidates and queries with additional data by calling external services. They run in parallel to maximize performance and can be used at multiple stages of the pipeline.

Hydrator Types

There are two types of hydrators:

Query Hydrators

Enrich the query with user features, experiment flags, and configuration

Candidate Hydrators

Enrich candidates with author info, media metadata, and additional features

Candidate Hydrator Trait

The Hydrator trait defines the interface for enriching candidates:
candidate-pipeline/hydrator.rs
The hydrate method must return candidates in the same order as the input. The returned vector must have the same length. Dropping or reordering candidates is not allowed - use a filter instead.

Query Hydrator Trait

The QueryHydrator trait defines the interface for enriching queries:
candidate-pipeline/query_hydrator.rs

Gizmoduck Hydrator

The Gizmoduck hydrator enriches candidates with author profile information:
home-mixer/candidate_hydrators/gizmoduck_hydrator.rs

Gizmoduck Features

  • Fetches user profile data for authors and retweeters
  • Batch fetches to minimize RPC calls
  • Deduplicates user IDs before fetching
  • Hydrates: author_followers_count, author_screen_name, retweeted_screen_name

Video Duration Hydrator

The Video Duration hydrator enriches candidates with video metadata:
home-mixer/candidate_hydrators/video_duration_candidate_hydrator.rs

Video Duration Features

  • Fetches media entities from Tweet Entity Service (TES)
  • Extracts video duration for video posts
  • Used by scorers to apply video-specific weights
  • Hydrates: video_duration_ms

Available Hydrators

The home-mixer service includes these candidate hydrators:

CoreDataCandidateHydrator

Hydrates core tweet data (text, media, metrics)

GizmoduckHydrator

Hydrates author profile information

InNetworkCandidateHydrator

Hydrates social graph features

SubscriptionHydrator

Hydrates subscription/premium status

VFCandidateHydrator

Hydrates visibility filtering results

VideoDurationCandidateHydrator

Hydrates video duration metadata

Parallel Execution

Hydrators run in parallel for maximum performance:
candidate-pipeline/candidate_pipeline.rs

Error Handling

If a hydrator fails or returns mismatched length, the error is logged and candidates remain unmodified. This ensures partial failures don’t break the pipeline.

Best Practices

Always batch external calls to minimize RPC overhead:
The hydrated vector must match the input order and length:
Only update fields this hydrator is responsible for:
Use Default::default() for fields you don’t hydrate:

Hydration Stages

Hydrators can run at two points in the pipeline:
1

Pre-Selection Hydration

Runs after candidate fetching, before filtering and scoring. Used for features needed for filtering/scoring.
2

Post-Selection Hydration

Runs after selection, only on candidates that will be returned. Used for expensive features only needed for display.
Use post-selection hydration for expensive operations that only need to run on the final selected candidates (e.g., fetching full tweet content, high-resolution images).

Pipeline Framework

Understand the overall pipeline execution flow

Sources

Learn how candidates are fetched

Filters

Filter candidates after hydration

Scorers

Score candidates using hydrated features