REST API unavailable warning persists after later startup requests succeed

[pirate-bot]

Summary

The Revive Social dashboard can retain its REST API unavailable warning after a startup request fails and another startup request later succeeds during the same page load. A successful recovery is expected to update the dashboard's warning state. Instead, the warning remains visible until the page is reloaded, making a transient failure appear current and potentially prompting unnecessary configuration troubleshooting.

Customer context

• Product / area: Revive Social dashboard used with the Pro Add-on
• Version: Pro Add-on 3.3.5; free/core plugin version not provided
• Environment: WordPress 7.1, PHP 8.3.21, managed hosting
• Integration / third party: WPML multilingual URL structure; JNews theme
• Reported error / symptom: REST API unavailable warning appears stale despite successful general REST checks
• Impact: A recovered or transient startup failure remains presented as an active configuration problem for the rest of the page load

Reproduction notes

1. Load the Revive Social dashboard in a controlled environment.
2. Make one Promise-based startup request fail.
3. Allow another Promise-based startup request to succeed afterward.
4. Observe that the REST API unavailable warning remains visible for the page load.
5. Reload the dashboard and observe that the new store initially resets the warning.

The state transition is source-confirmed in tag v9.4.2; no local browser reproduction was run.

Diagnosis

Conclusion

The dashboard uses one Boolean warning flag for concurrent startup requests. Rejection paths set it to true, but successful request paths do not clear it. Consequently, once any covered request fails, a later successful startup request cannot remove the warning during that page load. This is deterministic in the inspected source and matches the reported stale-warning behavior.

Where this likely occurs

• vue/src/models/rop_store.js — Vuex state and mutations.apiNotAvailable() lines 53–55 and 142–144: the shared flag starts as false and the mutation directly assigns the supplied value.
• vue/src/models/rop_store.js — Vuex actions.fetchAJAXPromise() lines 320–354: rejection paths set the flag to true; the success path at lines 331–341 updates request data without resetting the flag.
• vue/src/rop_main.js — dashboard created() lines 27–31: three Promise-based startup requests are dispatched together, allowing mixed success and failure outcomes in one page load.
• vue/src/vue-elements/main-page-panel.vue — MainPagePanel template lines 18–23 and computed property is_rest_api_error() lines 297–301: notice visibility directly follows the persistent shared flag.
• Git commit 55c777de introduced the flag and warning in 2018; commit a8c89268 added another catch path that also sets the flag. Tag v9.4.2 retains the behavior. No earlier release with verified success-clearing behavior was identified, so this is not classified as a regression.

Engineering notes

The three startup requests run concurrently and share state rather than tracking request outcomes separately. Their order does not provide a recovery path because no successful branch writes false. Reloading creates a new Vue store with the initial false value, which explains why a page reload resets the notice until another rejection occurs. The dashboard path is owned by the free/core repository; the inspected Pro repository does not provide an alternate production state lifecycle.

Test coverage status

No relevant coverage was found during inspection for mixed startup outcomes or warning recovery. tests/e2e/specs/dashboard/general-settings.spec.js lines 6–38 covers the normal successful dashboard path only. No inspected unit or integration test exercises api_not_available state transitions.

What to verify or explore next

• May be worth reproducing mixed startup outcomes with one delayed success after one failure and with the reverse completion order.
• May be worth checking whether user-triggered successful requests after startup also leave the warning visible.
• If reproducible, checking the Playwright dashboard suite with deterministic request interception would confirm the warning lifecycle at the public UI seam.

Unknowns / follow-up

• The customer's exact request completion order is unavailable.
• The paired free/core Revive Social version installed with Pro Add-on 3.3.5 is unknown.

Confidence

Confidence: 98/100

Repository inspection confirms two independently testable dashboard defects in the current tagged free-plugin source: request-specific failures are mapped to a core REST API warning, and the shared warning flag is not cleared by later successes. No matching open GitHub issue was found.

---

Source: HelpScout #3447403104
Generated by bug-report-triage (ID: bug-report-triage_6aa31a6d08a988.40680962)

[girishpanchal30]

I have fixed it with this PR #1127

[rodica-andronache]

🤖 Automated QA Repro Steps

The Revive Social dashboard raises its big red "core REST API functionality is not available" warning as soon as any one of its start-up requests fails — even when the others succeed and the dashboard loads perfectly. Once shown it stays up for the whole page load, so a single failing request looks like the site's REST API is down, and customers go chasing security plugins and hosting configuration that were never the problem.

Setup snippet — Code Snippets → Add New, title "Fail one ROP request", run everywhere

add_filter( 'rest_pre_dispatch', function ( $result, $server, $request ) {
	if ( false !== strpos( $request->get_route(), 'tweet-old-post/v8' )
		&& 'get_active_accounts' === $request->get_param( 'req' ) ) {
		return new WP_Error( 'qa_forced_failure', 'Forced failure for QA', array( 'status' => 500 ) );
	}

	return $result;
}, 10, 3 );

Reproduce on Revive Social 9.4.2:

1. Activate the setup snippet above — it fails only the get_active_accounts start-up request and leaves the other two working.
2. Open Revive Social in wp-admin and let the dashboard finish loading.

• Bug: the red "It seems there is an issue with your WordPress configuration and the core REST API functionality is not available…" warning sits at the top of the dashboard, even though the rest of the dashboard renders and works normally. It stays until you reload.
• Fixed: no warning at all — the dashboard loads clean, because the other start-up requests succeeded.

Edge cases

• Drop the req check from the snippet so every Revive Social request fails — the warning must still appear; this is the genuine-outage case and must not regress.
• Point the snippet at get_available_services or get_authenticated_services instead — same outcome, no warning.
• Deactivate the snippet, load the dashboard cleanly, then activate the fail-everything version and click Start/Stop sharing — the warning must appear for that failed action.
• Reload the dashboard after seeing the warning — its state must reflect the current load, not the previous one.
• Normal dashboard with a connected account and no snippet — no warning; accounts and schedules load as usual.

Fix: #1127 (open)