ActionScheduler_HybridStore is a wrapper store that reads from two stores and migrates actions from the legacy store to the custom-table store on demand. It lives in classes/data-stores/ActionScheduler_HybridStore.php.

Purpose

During migration from ActionScheduler_wpPostStore to ActionScheduler_DBStore, the hybrid store provides a seamless interface by:

• Reading from both stores
• Migrating legacy actions as they are accessed
• Writing all new actions to the primary (destination) store

Key Concepts

Primary and Secondary Stores

• Primary store: destination store (custom tables by default)
• Secondary store: source store (legacy WP posts)

The hybrid store obtains both from the migration Config object.

Demarkation ID

DEMARKATION_OPTION = action_scheduler_hybrid_store_demarkation

This stored option marks the dividing line between post IDs and custom table IDs, preventing collisions. It is set during table creation, using a value greater than the maximum wp_posts.ID.

Initialization

• init() hooks action_scheduler/created_table to set_autoincrement()
• Initializes both primary and secondary stores

set_autoincrement():

• Sets the actions table AUTO_INCREMENT to be higher than wp_posts.ID
• Inserts a temporary row with the demarkation ID to force the AUTO_INCREMENT value

Public API

Reads and Queries (with migration)

• find_action( $hook, $params = array() )
• query_actions( $query = array(), $query_type = 'select' )

Behavior:

1. Query the secondary store.
2. If any matches are found, migrate them immediately.
3. Return results from the primary store.

Counts

• action_counts() merges counts from both stores per status.

Claims

• stake_claim() first claims from the secondary store, migrates those actions, releases the claim, then claims from the primary store.

Claim-related methods (get_claim_count, get_claim_id, release_claim, unclaim_action, find_actions_by_claim_id) always operate on the primary store.

Writes

• save_action() writes only to the primary store.

Action Mutations

For methods that operate on an action ID, the hybrid store determines which store actually owns the action:

• fetch_action()
• cancel_action()
• delete_action()
• get_date()
• mark_failure()
• log_execution()
• mark_complete()
• get_status()

The internal resolver uses the demarkation ID and a fetch probe to decide the store.

Migration Trigger

Migration is handled by Action_SchedulerMigrationRunner:

• migrate() calls $this->migration_runner->migrate_actions( $action_ids ).

This occurs whenever the hybrid store finds legacy actions in the secondary store.

Data Persistence Summary

The hybrid store does not persist data itself. It delegates to:

• ActionScheduler_DBStore for new actions and canonical storage
• ActionScheduler_wpPostStore for legacy actions until they are migrated