ellite/Wallos · error · Error

translate("network_response_error")

Error message

translate("network_response_error")

What it means

renamePayment performs a fetch to a settings/payment endpoint and throws a generic Error with the localized message translate("network_response_error") whenever the HTTP response status is not OK (response.ok is false, i.e. status outside 200-299). It is a deliberately generic network/HTTP failure message shown to end users. The actual cause (404, 403, CSRF rejection, 500) is hidden behind this single message because the code does not inspect response.status or the response body.

Solutions

  1. Open the browser devtools Network tab, retry the rename, and check the actual HTTP status and response body of the failing request.
  2. Regenerate the page so window.csrfToken matches the current session (stale CSRF tokens cause 403/419 responses).
  3. Verify the fetch URL in renamePayment matches the server route for renaming payments.
  4. Improve the throw to include response.status and, when the body is JSON, data.message so the real server error surfaces instead of the generic message.

Example fix

// before
if (!response.ok) {
  throw new Error(translate("network_response_error"));
}
// after
if (!response.ok) {
  const body = await response.text();
  let serverMessage = "";
  try { serverMessage = JSON.parse(body).message ?? ""; } catch (e) {}
  throw new Error(`${translate("network_response_error")} (HTTP ${response.status})${serverMessage ? ": " + serverMessage : ""}`);
}
Defensive patterns

Strategy: try-catch

Validate before calling

function canSubmitPaymentRename() {
  return typeof window.csrfToken === 'string' && window.csrfToken.length > 0 && document.body.dataset.sessionActive === 'true';
}

Try / catch

renamePayment(...).catch(err => {
  if (/network_response_error/.test(err.message)) {
    showErrorMessage(`${translate('network_response_error')} — please reload the page and try again (session may have expired)`);
  } else {
    showErrorMessage(err.message);
  }
});

Prevention

When it happens

Trigger: Any fetch call in renamePayment that resolves with a non-2xx status: the endpoint URL changed or is wrong, the session expired, the X-CSRF-Token header is stale/missing and the server returns 419/403, or the server errors with 500 while processing the form data POST.

Common situations: Users with an expired PHP session or stale CSRF token submitting the rename form; a proxy or server returning 404 after a route rename; a backend exception returning 500 during the payment rename; deployments where the endpoint moved behind a new base path.

Understand the failure class

Background: "API error: {status}" and "HTTP 401/403/404/429/5xx" errors: non-2xx HTTP responses explained — this error's family across 27 libraries.

Related errors

AI-assisted analysis of ellite/Wallos@52820e87ca (2026-09-13). Data as JSON: /api/errors/2a64094c364e8345. Report an issue: GitHub.

Appendix: source

Thrown at scripts/settings.js:680

function renamePayment(paymentId, newName) {
  const name = newName.trim();
  if (!name) return;

  const formData = new FormData();
  formData.append("paymentId", paymentId);
  formData.append("name", name);

  fetch("endpoints/payments/rename.php", {
    method: "POST",
    headers: {
      "X-CSRF-Token": window.csrfToken,
    },
    body: formData,
  })
    .then(response => {
      if (!response.ok) {
        throw new Error(translate("network_response_error"));
      }
      return response.json();
    })
    .then(data => {
      if (data.success) {
        showSuccessMessage(`${newName} ${data.message}`);
      } else {
        showErrorMessage(data.message || translate("failed_save_payment_method"));
      }
    })
    .catch(error => {
      console.error(error);
      showErrorMessage(translate("unknown_error"));
    });
}


document.body.addEventListener('keypress', function (e) {

View on GitHub (pinned to 52820e87ca)