Summary
Posts selected within the configured maximum-age window can remain scheduled after they become older than that limit. Expected behavior is for a post to remain eligible only while it satisfies the configured age range. Actual behavior allows an already populated future queue slot to retain and later share the post without another age check. This can cause a news-focused sharing schedule to publish stale content.
Customer context
Product / area: Revive Social sharing queue and maximum post age
Version: Revive Social 9.4.0; Revive Social Pro Add-on 3.3.3
Environment: WordPress 7.0.2, PHP 8.3.30, single-site, UTC offset 0
Integration / third party: Facebook Pages
Reported error / symptom: A 0–3 day repost window includes older posts
Impact: Stale news articles can be reposted after leaving the intended freshness window.
Reproduction notes
- Configure a social account with a narrow maximum post age and a schedule that creates future queue events.
- Refresh the Sharing Queue while a post is still inside the eligible age window.
- Allow that queued post to cross the maximum-age boundary before its event becomes due.
- Inspect or execute the due event.
Repository inspection confirms the stale eligibility path; an isolated runtime reproduction was not performed. The transcript does not provide the affected post timestamps or corresponding Sharing Log entries.
Diagnosis
Conclusion
The defect is confirmed by repository inspection. The selector applies maximum age when building the eligible post pool, but complete existing queue entries are preserved without checking whether their post IDs remain in that pool. The recurring sharing job later consumes those stored IDs without reevaluating age. This permits a post that was eligible at queue-population time to be shared after crossing the maximum-age boundary.
Where this likely occurs
includes/admin/models/class-rop-posts-selector-model.php — Rop_Posts_Selector_Model::build_query_args() lines 594–648 applies the configured maximum age only to the post-selection query.includes/admin/models/class-rop-queue-model.php — Rop_Queue_Model::get_queue() lines 194–285 rebuilds the eligible pool, but lines 229–237 retain a complete queued event without comparing its stored post IDs with the current pool.includes/admin/models/class-rop-queue-model.php — Rop_Queue_Model::build_queue() lines 398–417 attaches the retained post IDs to event times without age validation.includes/admin/class-rop-admin.php — Rop_Admin::rop_cron_job() lines 1191–1289 consumes due queue entries and prepares their stored post IDs without a current-age eligibility check.includes/admin/models/class-rop-scheduler-model.php — Rop_Scheduler_Model::EVENTS_PER_ACCOUNT lines 15–19 keeps ten future events per account, allowing queued entries to cross the age boundary before execution.- Git history attributes the complete-entry preservation branch to commit
13e2274fd7209409c6c946e4e2be6eade1fa0d36 and shows it in releases from v8.0.0 through the reported v9.4.0.
Engineering notes
A normal General Settings save clears the current queue in includes/admin/models/class-rop-settings-model.php — Rop_Settings_Model::save_settings() lines 429–446, so entries that were already stale at save time are ordinarily removed. The confirmed gap occurs afterward as newly selected entries remain in future slots and continue aging. The amount of drift depends on the account schedule because ten future events are maintained. The selector also uses a calendar-date boundary rather than an exact rolling-hour duration; that boundary behavior may affect observed age near midnight but is not required for the queue-aging defect.
Test coverage status
tests/test-selector.php — Test_RopSelector::test_posts_selector() lines 34–47 verifies broad age-query direction with two-month-old posts, but not aging after selection. tests/test-queue.php — Test_RopQueue lines 17–142 covers queue consistency, removal, blocking, and post-count changes, but not revalidation of queued posts against age settings. No relevant coverage for posts crossing the maximum-age boundary while waiting in a future queue slot was found during inspection.
What to verify or explore next
- May be worth reproducing with a short maximum-age boundary and multiple future queue events, then running the due event after the selected post crosses that boundary.
- May be worth checking the Sharing Queue before and after the boundary to confirm the same post ID remains scheduled.
- If reproducible, checking
tests/test-queue.php and tests/test-selector.php together would establish the expected contract between current eligibility and persisted queue entries.
- Compatibility checks may include sparse and dense schedules, multiple Facebook accounts, and the
Share more than once setting.
Unknowns / follow-up
The transcript does not identify the exact ages or queue timestamps of the reported older posts, and the available diagnostics do not expose Revive Social settings or Sharing Logs. The customer-site instance was not used for runtime reproduction.
Confidence
Confidence: 94/100
Repository inspection confirms that posts can remain in future queue slots after they age beyond the configured maximum. The immediate-sharing and missing-image reports were not retained as product defects because the available evidence is consistent with the documented settings, asynchronous task execution, the previously stalled site task queue, featured-image availability, and Facebook link-preview behavior.
Source: HelpScout #3393452110
Generated by bug-report-triage (ID: bug-report-triage_6a6a158f8b4c93.25460145)
Summary
Posts selected within the configured maximum-age window can remain scheduled after they become older than that limit. Expected behavior is for a post to remain eligible only while it satisfies the configured age range. Actual behavior allows an already populated future queue slot to retain and later share the post without another age check. This can cause a news-focused sharing schedule to publish stale content.
Customer context
Product / area: Revive Social sharing queue and maximum post age
Version: Revive Social 9.4.0; Revive Social Pro Add-on 3.3.3
Environment: WordPress 7.0.2, PHP 8.3.30, single-site, UTC offset 0
Integration / third party: Facebook Pages
Reported error / symptom: A 0–3 day repost window includes older posts
Impact: Stale news articles can be reposted after leaving the intended freshness window.
Reproduction notes
Repository inspection confirms the stale eligibility path; an isolated runtime reproduction was not performed. The transcript does not provide the affected post timestamps or corresponding Sharing Log entries.
Diagnosis
Conclusion
The defect is confirmed by repository inspection. The selector applies maximum age when building the eligible post pool, but complete existing queue entries are preserved without checking whether their post IDs remain in that pool. The recurring sharing job later consumes those stored IDs without reevaluating age. This permits a post that was eligible at queue-population time to be shared after crossing the maximum-age boundary.
Where this likely occurs
includes/admin/models/class-rop-posts-selector-model.php—Rop_Posts_Selector_Model::build_query_args()lines 594–648 applies the configured maximum age only to the post-selection query.includes/admin/models/class-rop-queue-model.php—Rop_Queue_Model::get_queue()lines 194–285 rebuilds the eligible pool, but lines 229–237 retain a complete queued event without comparing its stored post IDs with the current pool.includes/admin/models/class-rop-queue-model.php—Rop_Queue_Model::build_queue()lines 398–417 attaches the retained post IDs to event times without age validation.includes/admin/class-rop-admin.php—Rop_Admin::rop_cron_job()lines 1191–1289 consumes due queue entries and prepares their stored post IDs without a current-age eligibility check.includes/admin/models/class-rop-scheduler-model.php—Rop_Scheduler_Model::EVENTS_PER_ACCOUNTlines 15–19 keeps ten future events per account, allowing queued entries to cross the age boundary before execution.13e2274fd7209409c6c946e4e2be6eade1fa0d36and shows it in releases fromv8.0.0through the reportedv9.4.0.Engineering notes
A normal General Settings save clears the current queue in
includes/admin/models/class-rop-settings-model.php—Rop_Settings_Model::save_settings()lines 429–446, so entries that were already stale at save time are ordinarily removed. The confirmed gap occurs afterward as newly selected entries remain in future slots and continue aging. The amount of drift depends on the account schedule because ten future events are maintained. The selector also uses a calendar-date boundary rather than an exact rolling-hour duration; that boundary behavior may affect observed age near midnight but is not required for the queue-aging defect.Test coverage status
tests/test-selector.php—Test_RopSelector::test_posts_selector()lines 34–47 verifies broad age-query direction with two-month-old posts, but not aging after selection.tests/test-queue.php—Test_RopQueuelines 17–142 covers queue consistency, removal, blocking, and post-count changes, but not revalidation of queued posts against age settings. No relevant coverage for posts crossing the maximum-age boundary while waiting in a future queue slot was found during inspection.What to verify or explore next
tests/test-queue.phpandtests/test-selector.phptogether would establish the expected contract between current eligibility and persisted queue entries.Share more than oncesetting.Unknowns / follow-up
The transcript does not identify the exact ages or queue timestamps of the reported older posts, and the available diagnostics do not expose Revive Social settings or Sharing Logs. The customer-site instance was not used for runtime reproduction.
Confidence
Confidence: 94/100
Repository inspection confirms that posts can remain in future queue slots after they age beyond the configured maximum. The immediate-sharing and missing-image reports were not retained as product defects because the available evidence is consistent with the documented settings, asynchronous task execution, the previously stalled site task queue, featured-image availability, and Facebook link-preview behavior.
Source: HelpScout #3393452110
Generated by bug-report-triage (ID: bug-report-triage_6a6a158f8b4c93.25460145)