What causes "Network response was not ok" in dotnet/orleans?

Inspect the response status/body in devtools Network tab for the failing POST to read the server-side error.

dotnet/orleans · warning · Error

Network response was not ok

Error message

Network response was not ok

What it means

A browser-side Error thrown by postRequest() in the ActivationRepartitioning frontend when a POST (e.g., to /add) returns a non-2xx status. Like all fetch calls, the network layer only rejects on network failure, so the code checks response.ok manually and throws to send control into the catch, which logs the error and swallows it.

Source

Thrown at playground/ActivationRepartitioning/ActivationRepartitioning.Frontend/wwwroot/index.html:338

          height = svg.node().clientHeight;
          state.simulation.force(
            "center",
            d3.forceCenter(width / 2, height / 2)
          );
          state.simulation.alpha(1).restart();
        });
      }

      async function postRequest(url) {
        try {
          const response = await fetch(url, {
            method: "POST",
            headers: {
              "Content-Type": "application/json",
            },
          });
          if (!response.ok) {
            throw new Error("Network response was not ok");
          }
          await loadData();
        } catch (error) {
          console.error("Error with the fetch operation:", error);
        }
      }

      document
        .getElementById("addGrainsButton")
        .addEventListener("click", () => {
          postRequest("/add");
        });

      document.getElementById("resetButton").addEventListener("click", () => {
        postRequest("/reset");
      });
    </script>
  </body>

View on GitHub (pinned to fca799fa70)

Solutions

Inspect the response status/body in devtools Network tab for the failing POST to read the server-side error.
Check backend logs for the exception thrown while handling the POST.
Verify the cluster client is still connected (gateway reachable) before issuing the POST.

Example fix

// before
if (!response.ok) {
  throw new Error("Network response was not ok");
}

// after (include status for actionable diagnostics)
if (!response.ok) {
  throw new Error(`Request to ${url} failed: ${response.status} ${response.statusText}`);
}

Defensive patterns

Strategy: try-catch

Try / catch

async function postRequest(url) {
  try {
    const response = await fetch(url, { method: 'POST', headers: { 'Content-Type': 'application/json' } });
    if (!response.ok) throw new Error(`${url} failed: ${response.status}`);
    await loadData();
  } catch (error) {
    console.error('Fetch failed:', error);
    alert('Operation failed: ' + error.message);
  }
}

Prevention

Include status and URL in thrown errors for traceability.
Give the user feedback (toast/alert) on failure rather than silently logging.
Validate any request body before posting to reduce 4xx errors.

When it happens

Trigger: Clicking the 'Add Grains' button (or any control wired to postRequest) issues fetch(url,{method:'POST'}) and the server responds with an error status. The accompanying loadData() refresh is skipped because the throw precedes it.

Common situations: The backend grain-add endpoint rejected the request (capacity, validation, or a thrown exception in the grain). The Orleans client lost connectivity to the cluster. The endpoint route changed.

Related errors

AI-assisted analysis of dotnet/orleans@fca799fa70 (2026-08-13). Data as JSON: /api/errors/2349bb87f069c707. Report an issue: GitHub.