antiwork/gumroad · error · ResponseError

Something went wrong.

Error message

Something went wrong.

What it means

ResponseError ('Something went wrong.') thrown at profile_settings.ts:102 when the GET to Routes.profile_product_path(id) returns non-ok (a 4xx; 5xx/429/network are thrown earlier inside request()). getProduct fetches a single product's data for the profile editor; the throw means the server rejected the id — in practice an unknown or inaccessible product — and the generic message drops the status detail.

Source

Thrown at app/javascript/data/profile_settings.ts:102

      // Omit pages/sections entirely when the caller didn't pass them, so a settings-only save
      // doesn't replace (and prune) the server's section list. When they are sent, profile_version
      // lets the server reject the write if the layout changed elsewhere since this editor loaded.
      ...(tabs !== undefined ? { tabs } : {}),
      ...(sections !== undefined ? { sections } : {}),
      ...(profileVersion !== undefined ? { profile_version: profileVersion } : {}),
    },
  });
  const json = typia.assert<{ success: false; error_message: string } | { success: true }>(await response.json());
  if (!json.success) throw new ResponseError(json.error_message);
};

export const getProduct = async (id: string) => {
  const response = await request({
    method: "GET",
    url: Routes.profile_product_path(id),
    accept: "json",
  });
  if (!response.ok) throw new ResponseError();
  return typia.assert<ProductProps>(await response.json());
};

export const unlinkTwitter = async () => {
  const response = await request({
    method: "POST",
    url: Routes.unlink_twitter_settings_connections_path(),
    accept: "json",
  });
  const json = typia.assert<{ success: false; error_message: string } | { success: true }>(await response.json());
  if (!json.success) throw new ResponseError(json.error_message);
};

View on GitHub (pinned to afeacbd394)

Solutions

  1. Check the GET status in DevTools: 404 → bad id, 401/403 → session or access problem
  2. Source the id from freshly loaded profile data rather than persisted editor state
  3. On 404, drop the missing product from the editor's list and continue instead of blocking the whole profile editor
  4. On 401, prompt re-authentication and retry once
  5. If products disappear right after seller actions elsewhere (delete in another tab), refresh the editor's product list before editing

Example fix

// before
if (!response.ok) throw new ResponseError();

// after
if (!response.ok) {
  if (response.status === 404) throw new ResponseError('Product not found.');
  const body = await response.json().catch(() => null) as { error?: string } | null;
  throw new ResponseError(body?.error ?? `Failed to load product (${response.status})`);
}
Defensive patterns

Strategy: fallback

Validate before calling

const knownProduct = (id: string, productIds: string[]): boolean => productIds.includes(id);

Type guard

import { assertResponseError } from '$app/utils/request';
assertResponseError(e);

Try / catch

try {
  return await getProduct(id);
} catch (e) {
  assertResponseError(e);
  // a missing product shouldn't block the whole profile editor — skip it
  return null;
}

Prevention

When it happens

Trigger: 404 when id doesn't resolve (deleted product, draft not visible to this user, id from another environment); 401/403 when the editor's session lacks access to that product; malformed ids (truncated query param, stale cached state) failing lookup.

Common situations: Profile editor restored from a local-storage draft referencing a deleted product; seller deletes a product in one tab while the profile editor lists it in another; id persisted before a permalink-to-id migration; shared or bookmarked editor URLs going stale.

Related errors


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