Authorization callback reload can discard the first social account #1111

Summary

After a user completes social-network authorization, the dashboard can reload before the new account finishes saving. The connected account is expected to appear in Revive Social after authorization, but the user can instead return to the dashboard with no account connected. This blocks initial setup and prevents the plugin from being used for sharing.

Customer context

• Product / area: Revive Social account connection
• Version: 9.4.0
• Environment: WordPress environment and browser not provided
• Integration / third party: Social network not identified
• Reported error / symptom: Login completed, but the first account was not connected in the plugin
• Impact: Initial setup failed; the plugin was deactivated after 13 minutes

Reproduction notes

Reported sequence:

1. Install or activate Revive Social 9.4.0 with no connected accounts.
2. Start the connection flow for the first social account.
3. Complete login in the authorization window.
4. Return to the plugin and observe that no account was connected.

Repository-confirmed trigger: the 9.4.0 callback can reload while the add-account REST request remains in flight. Runtime reproduction was not performed, and the affected social network and timing conditions are unknown.

Diagnosis

Conclusion

The account-connection callback in the v9.4.0 source starts the add-account REST request but does not return or await that request before reloading the dashboard. A browser may cancel the in-flight request, leaving no persisted account. Post-release commit 53b2d9a5c39a9f2361a59417bffde52cd63ef6f5 explicitly describes this data-loss race and introduces completion tracking before reload, providing strong repository evidence for the reported symptom.

Where this likely occurs

• vue/src/vue-elements/sign-in-btn.vue — SignInBtn::addAccountFB(), addAccountTW(), addAccountLI(), addAccountTumblr(), addAccountGmb(), and addAccountVk() approx. lines 738–864: each dispatches account persistence without returning its promise to the callback.
• vue/src/vue-elements/sign-in-btn.vue — SignInBtn::getChildWindowMessage() lines 889–928: dispatches the relevant add-account method, performs tracking, and reloads without confirming persistence completed.
• vue/src/models/rop_store.js — Vuex fetchAJAXPromise() lines 320–353: the REST request is asynchronous; request failure branches in the inspected version also do not reject the wrapping promise.
• Git history: v9.4.0 (2026feb4) contains the vulnerable flow. Commit 53b2d9a5 on origin/bugfix/1099 states that reload can abort the request and lose the account; no release tag contains that commit in the inspected repository.

Engineering notes

The inspected callback handles Facebook/Instagram, X/Twitter, LinkedIn, Tumblr, Google Business Profile, and VK through the same asynchronous dispatch pattern, but the uninstall report does not identify which network failed. Valid first-account payloads are activated and persisted by the service/model path, so the strongest evidence points to the handoff between the authorization callback and REST persistence rather than first-account model logic. The external authorization application is outside the available repository and was not inspected.

Test coverage status

tests/e2e/specs/dashboard/accounts.spec.js lines 6–23 only checks that social-account buttons are visible. tests/test-accounts.php lines 28–51 covers seeded model state, and lines 66–102 covers service construction and sign-in URL generation. No relevant coverage was found during inspection for authorization-window messages, waiting for an add-account REST request, dashboard reload timing, or persistence of a first real social account.

What to verify or explore next

• Reproduce a first account connection on v9.4.0 with network throttling and confirm whether reload cancels the add_account_* request.
• Verify the callback flow separately for each supported popup-based social network because the report does not identify one.
• Run the dashboard Playwright suite in tests/e2e/specs/dashboard/accounts.spec.js and inspect whether an authorization-message seam can exercise persistence completion before navigation.
• Compare the behavior with origin/bugfix/1099 at commit 53b2d9a5 to confirm the reported failure no longer occurs under the same timing.

Unknowns / follow-up

The social network, browser, WordPress/PHP versions, callback payload, console output, and failed request details were not provided. The exact customer incident was not reproduced at runtime.

Confidence

Confidence: 92/100

The 9.4.0 tagged callback starts account persistence asynchronously and reloads the dashboard without waiting for completion; post-release commit 53b2d9a5 explicitly identifies that race as allowing the request to be canceled and the account to be lost. This directly matches the reported completed login followed by no connected account, although the specific network and browser timing are unknown.

Source: automated uninstall feedback — tweet-old-post, 2026-08-21
Generated by bug-report-triage (ID: bug-report-triage_6a892d06cd91e4.14376476)