antiwork/gumroad · error · ResponseError
responseData.error_message
Error message
responseData.error_message
What it means
ResponseError thrown at publish_product.ts:14 whose message is responseData.error_message from POSTing Routes.publish_link_path(id) or Routes.unpublish_link_path(id): setProductPublished toggles a product's publish state and the server answered { success: false, error_message }, which is forwarded verbatim. There is no response.ok check — the endpoint is trusted to speak the TogglePublishStateResponse envelope (typia.assert enforces it at runtime).
Source
Thrown at app/javascript/data/publish_product.ts:14
import typia from "typia";
import { request, ResponseError } from "$app/utils/request";
type TogglePublishStateResponse = { success: true } | { success: false; error_message: string };
export async function setProductPublished(id: string, publish: boolean) {
const response = await request({
url: publish ? Routes.publish_link_path(id) : Routes.unpublish_link_path(id),
method: "POST",
accept: "json",
});
const responseData = typia.assert<TogglePublishStateResponse>(await response.json());
if (!responseData.success) throw new ResponseError(responseData.error_message);
}
View on GitHub (pinned to afeacbd394)
Solutions
- Read the thrown error_message — it names the unmet publish precondition; satisfy it (upload required assets, set price or quantity) and retry the toggle
- Refetch the product after failure so the UI reflects the server's authoritative published state, not the optimistic one
- Guard double-clicks: disable the publish/unpublish control while the POST is pending
- If the toggle silently reverts, watch the publish/unpublish POST in DevTools — a success:false with a quiet toast is the usual culprit
- If error_message is empty in production, fix the endpoint to always populate it so this error is diagnosable
Defensive patterns
Strategy: try-catch
Type guard
import { assertResponseError } from '$app/utils/request';
assertResponseError(e); // e.message names the unmet publish precondition Try / catch
try {
await setProductPublished(id, publish);
} catch (e) {
assertResponseError(e);
showError(e.message); // e.g. missing thumbnail or price — show the server's reason
await refetchProduct(id); // revert the optimistic toggle to the server's state
} Prevention
- Show error_message verbatim; it tells the seller exactly what to fix before publishing
- Refetch the product after failure so the publish toggle reflects server truth
- Disable the toggle while the POST is in flight
- Fix the endpoint if error_message ever comes back empty — the client depends on it
When it happens
Trigger: Publish refused because required attributes are missing (no price on a paid product, no content files attached, required description or cover missing); unpublish refused for products referenced by active bundles or with in-flight purchases; permission failures on products the caller doesn't own.
Common situations: Seller clicks 'Publish' on a half-configured draft; unpublishing a product embedded in a live bundle; UI optimistically flipping the toggle before the server confirms and getting refused; empty error_message strings after backend refactors leaving users with blank error toasts.
Related errors
- json.message
- json.error_message
- Failed to archive product
- Failed to unarchive product
- json.error_message
AI-assisted analysis of antiwork/gumroad@afeacbd394 (2026-08-21).
Data as JSON: /api/errors/d812a32a17136c1d.
Report an issue: GitHub.