Add request timeout + explicit error state to WhatsApp HTTP helpers#11
Draft
posthog[bot] wants to merge 1 commit into
Draft
Add request timeout + explicit error state to WhatsApp HTTP helpers#11posthog[bot] wants to merge 1 commit into
posthog[bot] wants to merge 1 commit into
Conversation
The shared HTTP helpers (lib/http.js, lib/request.mjs metaProxyRequest) used by
every flow/template/data-endpoint script issued a bare fetch with no timeout, so
a slow or hung Meta/Platform call left the script spinning forever with no
feedback — the agent-tooling analog of the "Sync from Meta" hang.
Bound each request with an AbortController (default 30s, override via
KAPSO_HTTP_TIMEOUT_MS). On timeout the CJS helper throws a RequestError with
status 408 and { timedOut: true }, and the ESM helper returns
{ ok: false, status: 408, timedOut: true } with a clear message, so callers
surface an actionable error instead of hanging.
Also sharpen the integrate-whatsapp SKILL troubleshooting: blank/preview-URL
flow previews map to a missing data endpoint, scoped listings return empty on a
mismatched phone_number_id/WABA, and document the new timeout behavior.
paths:
plugins/kapso/skills/integrate-whatsapp/scripts/lib/http.js
plugins/kapso/skills/integrate-whatsapp/scripts/lib/request.mjs
plugins/kapso/skills/integrate-whatsapp/SKILL.md
Generated-By: PostHog Code
Task-Id: a2dfd3bf-2074-49b4-8ae8-150079840501
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Users setting up WhatsApp hit dead-ends on the "Sync from Meta" import path: the action does nothing or hangs on an indefinite spinner, so flows/templates never appear. The report traces this through the helper scripts that mirror the same Meta/Platform API surface, and names the root-cause class directly:
lib/request.mjs(metaProxyRequest) andlib/http.js"have no timeout or error state, so a slow or failed Meta call spins forever."That's literally true here — both helpers issued a bare
fetchwith no timeout. They back every flow/template/data-endpoint script an agent runs, including the chat-assistant recovery path one blocked user fell back on. So the same hang-forever failure exists on the agent-tooling surface, and is fixable in this repo.What changed
lib/http.js/lib/request.mjs: bound each request with anAbortController. Default 30s, override viaKAPSO_HTTP_TIMEOUT_MS. On timeout the CJS helper throws aRequestError(status408,{ timedOut: true }) and the ESM helper returns{ ok: false, status: 408, timedOut: true }with a clear message — so a slow/hung Meta call surfaces an actionable error instead of spinning forever. Happy-path behavior is unchanged.SKILL.md: documentKAPSO_HTTP_TIMEOUT_MS; sharpen troubleshooting so a blank/preview-URL flow preview maps to a missing data endpoint (with aget-data-endpoint.jscheck), and note that scopedlist-flows/list-templatesreturn empty on a mismatchedphone_number_id/WABA rather than erroring.Verification
408timedOuterror (verified ~800ms withKAPSO_HTTP_TIMEOUT_MS=800); the process exits cleanly (no dangling timer).npm run validateandnpm run check:syntaxpass.Scope / honest limitation
The button, Flows/Templates pages, blank preview, and Inbox composer the affected users actually saw live in the Kapso web-app/platform repos, not here — this change does not by itself alter that browser behavior. It hardens the agent/CLI surface (the documented workaround + chat-assistant recovery path) against the same root cause and gives those tools a clear, bounded error instead of an indefinite hang. The web-app "Sync from Meta" handler still needs the equivalent timeout + success/error UI states, and the error-tracking instrumentation the report calls for, in the platform repo.
Created with PostHog Code from an inbox report.