Skip to content

fix: ack MULTIPOST_EXTENSION_PUBLISH so callers don't hit timeout#211

Draft
harryisfish wants to merge 1 commit into
mainfrom
feature/ack-publish-message
Draft

fix: ack MULTIPOST_EXTENSION_PUBLISH so callers don't hit timeout#211
harryisfish wants to merge 1 commit into
mainfrom
feature/ack-publish-message

Conversation

@harryisfish
Copy link
Copy Markdown
Contributor

Summary

The web client (`leaperone/MultiPost` → `apps/web/lib/extension/index.ts` `funcPublish`) sends a `MULTIPOST_EXTENSION_PUBLISH` message through the content-script bridge, which uses `chrome.runtime.sendMessage` and awaits the response. The background handler opened a popup but never called `sendResponse` — combined with the listener's `return true` (kept the port open), this meant `funcPublish` always waited the full 30s before reporting a fake failure.

Evidence (web-side PostHog, 7 days)

event count
`publish_initiated` 812
`publish_failed` 792 (all "Request timeout after 30000ms")
`publish_success` 0

That's a 97.5% false failure rate — but the actual publish flow works fine for users; only the web-side promise hangs.

Change

One-line ACK in the `MULTIPOST_EXTENSION_PUBLISH` branch:

```ts
sendResponse({ queued: true });
```

The popup-driven publish flow is unchanged. The real result still flows through `MULTIPOST_EXTENSION_PUBLISH_NOW` later.

Companion PR

The web side has a complementary fix (`leaperone/MultiPost#251`) that splits the event into `publish_dispatched` and drops timeout-flavored `publish_failed` reports. With both PRs landed, `funcPublish` will resolve with `{ success: true }` immediately upon ACK, and the false-failure noise goes away.

Test plan

  • Build extension, load unpacked in Chrome
  • Open multipost.app, trigger a publish — verify popup opens and the caller's promise resolves quickly (not after 30s)
  • No regression in actual publish flow (MULTIPOST_EXTENSION_PUBLISH_NOW path)

The web client (apps/web/lib/extension/index.ts funcPublish) sends a
MULTIPOST_EXTENSION_PUBLISH message through the content-script bridge,
which uses chrome.runtime.sendMessage and awaits the response. The
background handler opened a popup but never called sendResponse - combined
with the listener's return true (kept the port open), this meant
funcPublish always waited the full 30s before reporting a fake failure.

Production impact (web-side PostHog over 7 days):
  publish_initiated  = 812
  publish_failed     = 792  (all Request timeout after 30000ms)
  publish_success    = 0

This change adds a synchronous sendResponse({ queued: true }) so the
caller resolves immediately. The popup-driven publish flow is unchanged;
the real result still flows through MULTIPOST_EXTENSION_PUBLISH_NOW.
@leaperone-bot
Copy link
Copy Markdown

🤖 Leo

Code Review

⏳ 等待审查...

最后更新: 2026-05-20 14:55 · 2a372a2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants