Diagnosing Remix Action Failures: Silent Form Posts, Auth Gaps, and Upload Limits

Silent Form Failures in Remix Actions

A Remix form posts, the network tab shows a 200, the page re-renders, and nothing changed. No row was written, no error appeared, and useActionData() returns undefined. That combination points at an action that either never ran, ran without returning a response, or ran without the authentication you assumed the route already enforced.

Takeaway: An action is an ordinary server function exported from a route module. It is not cached like a loader, it is not covered by the loader's auth check on the same route, and it is not protected by any client-side validation. Most silent failures come from one of those three assumptions.

Symptom-to-Cause Table

Ordered Diagnostic Checks

1. Confirm which route received the POST

Remix matches the submission to a route module by URL. A form rendered by routes/projects.new.tsx posts to /projects/new unless it sets an action attribute, in which case it posts wherever that attribute points. If the target route has no exported action, Remix has nothing to call.

Open the browser's DevTools Network panel and submit. Confirm the method is POST and the path matches the module you edited. A POST that lands on a parent route's URL, such as /projects instead of /projects/new, invokes the parent's action, not yours.

2. Confirm the action returns a Response

Actions must return a Response, normally built with the json() helper. A function that falls off the end returns undefined, and useActionData() stays empty.

import { json, type ActionFunctionArgs } from "@remix-run/node";

// Broken: no return on the success path
export async function action({ request }: ActionFunctionArgs) {
  const form = await request.formData();
  await db.user.create({ email: form.get("email") });
}

// Fixed: every path returns a Response
export async function action({ request }: ActionFunctionArgs) {
  const form = await request.formData();
  const email = form.get("email");
  if (typeof email !== "string" || !email.includes("@")) {
    return json({ fieldErrors: { email: "Enter a valid email" } }, { status: 400 });
  }
  const user = await db.user.create({ email });
  return json({ user }, { status: 201 });
}

Expected check: after a valid submit, useActionData() in the component should hold the parsed JSON. If it is undefined, add a log line at the top of the action to see whether it ran at all.

3. Confirm validation runs server-side

Actions execute on every request that reaches them, including direct fetch calls and submissions from browsers with JavaScript disabled. Client-side checks are a UX convenience, not a control.

const raw = form.get("displayName");
const name = typeof raw === "string" ? raw.trim() : "";
if (name.length < 2 || name.length > 50) {
  return json({ fieldErrors: { displayName: "2-50 characters" } }, { status: 400 });
}

Expected check: disable JavaScript in the browser, submit invalid input, and confirm the server still returns 400 with structured errors.

4. Confirm the action authenticates independently

Loaders and actions on the same route are separate entry points. A loader that redirects unauthenticated users does nothing for the action.

async function requireUserId(request: Request) {
  const session = await getSession(request.headers.get("Cookie"));
  const userId = session.get("userId");
  if (!userId) throw redirect("/login");
  return userId;
}

export async function loader({ request }: LoaderFunctionArgs) {
  const userId = await requireUserId(request);
  return json({ posts: await db.post.findMany({ where: { userId } }) });
}

export async function action({ request }: ActionFunctionArgs) {
  const userId = await requireUserId(request); // required here too
  const form = await request.formData();
  return json({ post: await db.post.create({ title: String(form.get("title")), userId }) });
}

Expected check: from the browser console while logged out, send a POST to the route with a FormData body. The response should be a redirect to the login page, not a created record.

5. Confirm the request body fits platform limits

request.formData() buffers the body in memory. The runtime in front of your app, whether Node behind a proxy, Vercel, or Cloudflare Workers, enforces its own maximum request size. When that limit is exceeded, the request is rejected before your action's first line executes, which is why the failure looks unrelated to your code.

Expected check: send a file just over the documented limit for your host and watch whether the request reaches the action. For large media, the usual fix is a signed upload URL that lets the browser write directly to object storage, with the action storing only the resulting key.

Fixes Matched to Findings

When to Escalate Beyond Application Code

• Host limits you cannot raise, such as request size or CPU time. Move the work out of the action rather than fighting the platform.
• Lost updates from concurrent actions on the same record. Add a version column or wrap the write in a transaction.
• Cookie-based sessions without SameSite protection or a CSRF token. Treat this as a security review item, not a bug fix.
• Runtime-specific formData() parsing differences. Reproduce on the deployment runtime, since local Node behavior may not match an edge runtime.

Verification and Limitations

1. Submit with JavaScript enabled and confirm useActionData() updates the UI.
2. Disable JavaScript and submit again; the server should still return the correct status and rendered result.
3. Check the Network tab for a single request whose status matches the outcome, such as 201 created, 400 validation, or 302 redirect.
4. POST to the route without a session cookie and confirm the auth check fires.
5. Test boundary inputs: empty strings, maximum-length values, and a file just over your host's limit.

This describes Remix v2 conventions, where actions receive an ActionFunctionArgs object and typically return json(). Remix v1 typed these differently, and the json() helper sets Content-Type: application/json; returning a bare Response means setting headers yourself. Body-size limits, session helpers, and formData() memory behavior vary by runtime, so confirm the numbers against your host's documentation before relying on them.