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

  1. Read the thrown error_message — it names the unmet publish precondition; satisfy it (upload required assets, set price or quantity) and retry the toggle
  2. Refetch the product after failure so the UI reflects the server's authoritative published state, not the optimistic one
  3. Guard double-clicks: disable the publish/unpublish control while the POST is pending
  4. If the toggle silently reverts, watch the publish/unpublish POST in DevTools — a success:false with a quiet toast is the usual culprit
  5. 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

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


AI-assisted analysis of antiwork/gumroad@afeacbd394 (2026-08-21). Data as JSON: /api/errors/d812a32a17136c1d. Report an issue: GitHub.