[BUG]: Browser extension remains permanently locked after partial_success status updates

[VarshithReddy2006]

Description

Summary

The browser extension can become permanently locked after receiving a partial_success response from the backend.

When publishing succeeds on some platforms but fails on others, the background script converts the backend status from partial_success to warning and sends a STATUS_UPDATE message. However, the content script only clears its processing lock for success and error statuses.

As a result, the internal isProcessing flag remains true, preventing all future blog-generation attempts until the page is manually refreshed.

---

Location

extension/content.js

} else if (request.type === 'STATUS_UPDATE') {
    if (request.status === 'success' || request.status === 'error') {
        isProcessing = false;
    }
}

extension/background.js

status: data.status === 'partial_success' ? 'warning' : 'success',

(Occurs in multiple message dispatch paths.)

---

Root Cause

The extension uses an isProcessing flag as a mutex to prevent duplicate blog-generation requests.

The flag is set when generation starts:

if (isProcessing) return;
isProcessing = true;

and is only cleared when a status update contains:

success

or

error

However, the background script emits:

warning

For backend partial_success responses.

Since warning is not treated as a terminal state by the content script, the processing lock is never released.

---

Steps to Reproduce

1. Configure multiple publishing platforms (for example, Dev.to and LinkedIn).
2. Make one platform succeed and another fail (for example, revoke LinkedIn credentials while keeping Dev.to configured correctly).
3. Trigger blog generation from a solved LeetCode problem.
4. Allow the backend to return a partial_success response.
5. Observe that the extension reports a warning state.
6. Attempt to trigger blog generation again.

---

Expected Behaviour

After any terminal result (success, error, or partial_success), the extension should release the processing lock and allow future blog-generation requests.

---

Actual Behaviour

The extension receives a warning status update, but isProcessing remains true.

Subsequent generation attempts are blocked by:

if (isProcessing) return;

requiring the user to refresh the page to recover.

---

Impact

• Users cannot generate another blog after a partial publication failure.
• The extension appears stuck even though processing has completed.
• Manual page refreshes are required to restore functionality.
• Automated publishing workflows become unreliable.

---

Severity

High

Confidence

High

Suggested Fix

Treat warning as a terminal state and release the processing lock:

const terminalStates = ['success', 'error', 'warning'];

if (terminalStates.includes(request.status)) {
    isProcessing = false;
}

or otherwise ensure that all completed processing states clear the isProcessing flag.

[VarshithReddy2006]

Hi @vanshaggarwal27,

I investigated the extension message flow and identified the root cause of this issue.

The background script converts backend partial_success responses into a warning status, but the content script only releases the isProcessing lock when receiving success or error. As a result, any partial publication outcome leaves the extension stuck in a processing state and blocks all future blog-generation attempts until the page is refreshed.

I verified the execution path across both extension/background.js and extension/content.js and would like to work on implementing a fix.

Please assign this issue to me under GSSoC'26.

Thank you!

[VarshithReddy2006]

Hi @vanshaggarwal27,

Just following up on this issue. I'd still be happy to work on fixing it as part of GSSoC'26 if it's available.

Since I investigated the issue and documented the root cause, I'd appreciate it if you could assign it to me.

Thank you!

[VarshithReddy2006]

Hi @vanshaggarwal27,

Thank you for assigning me this issue.

I've completed the implementation and opened PR #220 to address it.

Summary of the fix

• Treated warning as a terminal processing state.
• Released the isProcessing mutex for success, error, and warning.
• Kept the change minimal and scoped only to the affected content-script logic.

This prevents the extension from remaining locked after partial_success responses while preserving the existing behavior for all other processing states.

Kindly review PR #220 when you have time. Thank you!