LinkedIn authorization errors can trigger a WordPress critical-error screen

[pirate-bot]

Summary

When LinkedIn returns an authorization failure during account reconnection, Revive Social can display a WordPress critical-error screen instead of preserving the dashboard and presenting the authorization error. The expected behavior is a recoverable error that explains the failed connection. The reported behavior interrupts reconnection and masks the original LinkedIn response.

Customer context

Product / area: Revive Social, LinkedIn account authorization
Version: Revive Social 9.4.0; Pro Add-on 3.3.3
Environment: WordPress 7.0.2; PHP 8.2
Integration / third party: LinkedIn OAuth through the Revive Social authorization application
Reported error / symptom: There has been a critical error on this website.
Impact: LinkedIn account reconnection cannot be completed and the underlying authorization error is hidden.

Reproduction notes

1. In Revive Social 9.4.0 with Pro Add-on 3.3.3, open Dashboard > Accounts > LinkedIn.
2. Start Sign in to LinkedIn and reach an authorization failure during reconnection.
3. Reported result: WordPress displays its critical-error screen rather than the LinkedIn error.

The customer reproduced the symptom, and staff identified the authorization handler as defective. No runtime reproduction or PHP stack trace was available during triage.

Diagnosis

Conclusion

The LinkedIn authorization path contains definite error-handling defects consistent with the reported critical-error screen. Staff explicitly identified the current authorization handler as masking LinkedIn errors with a critical error. Repository inspection found that the built-in application path accepts insufficiently validated account data and performs array operations on assumed fields, while the custom-application exception handler calls a method that standard PHP Exception does not provide. The attachment mentioned in the ticket was unavailable, so the exact fatal branch remains unknown.

Where this likely occurs

• LinkedIn account reconnection is opened against the external authorization application defined at tweet-old-post.php lines 177–182 in the plugin bootstrap constants.
• vue/src/vue-elements/sign-in-btn.vue — getChildWindowMessage() lines 889–915 parses every accepted-origin message as account data and sends LinkedIn messages to addAccountLI() without distinguishing an authorization-error payload.
• includes/admin/class-rop-rest-api.php — Rop_Rest_Api::add_account_li() lines 1189–1214 ignores the boolean result of account-data loading and continues into service/account processing.
• includes/admin/services/class-rop-linkedin-service.php — Rop_Linkedin_Service::add_account_with_app() lines 840–888 validates only id, then assumes pages, notification metadata, account fields, and at least one account are valid. On PHP 8.2, malformed values can reach typed array operations that raise a fatal error.
• includes/admin/services/class-rop-linkedin-service.php — Rop_Linkedin_Service::authorize() lines 120–149 catches Exception and calls $e->getDescription() at line 138; that method is not part of standard PHP Exception, so an exception during the custom-app token exchange enters a second fatal path.
• The reported Lite version corresponds to tag v9.4.0. No LinkedIn error-handling change was found between v9.3.6 and v9.4.0; this does not appear newly introduced in 9.4.0.

Engineering notes

The Pro add-on enables LinkedIn and its two-step sign-in in includes/admin/class-rop-pro-admin.php — Rop_Pro_Admin::available_services() lines 68–95, but the callback UI and persistence logic are owned by the Lite repository. The normal built-in flow depends on app.revive.social, whose server implementation is not present in the workspace. The standard PHP exception API was not inferred from WordPress core code. The inspected plugin code itself proves the non-standard method call and unsafe payload assumptions, but the missing runtime log prevents attribution of this customer event to one branch.

Test coverage status

No relevant coverage was found during inspection for LinkedIn authorization-error payloads, Rop_Rest_Api::add_account_li(), Rop_Linkedin_Service::add_account_with_app(), or exception handling in Rop_Linkedin_Service::authorize(). tests/test-legacy-auth-cap.php — test_subscriber_blocked_on_linkedin_callback() lines 81–99 covers only the capability guard before the callback. tests/e2e/specs/dashboard/accounts.spec.js line 18 checks only that the LinkedIn button is visible.

What to verify or explore next

• May be worth reproducing a denied LinkedIn authorization and a token-exchange error under PHP 8.2 while capturing the PHP fatal details.
• May be worth exercising the built-in callback with missing, invalid, and error-shaped pages data through the existing REST endpoint.
• If reproducible, checking the external authorization application's exact error payload would identify which plugin branch receives it.
• The focused PHPUnit suite around legacy authorization and the account dashboard E2E suite are relevant verification surfaces.

Unknowns / follow-up

The technical error log mentioned in the ticket was not available through HelpScout images or attachments. It is unknown whether the reported event used the built-in application data path or the custom LinkedIn application callback.

Confidence

Confidence: 88/100

Two independently testable LinkedIn authorization defects are supported by repository inspection and the staff-confirmed ticket symptom. The X credit failure was excluded because code and prior cases show Revive Social relays an upstream credit-depletion response rather than causing it.

---

Source: HelpScout #3396932665
Generated by bug-report-triage (ID: bug-report-triage_6a639a27a22a63.23975204)