Return non-200 responses from actions

[LexSwed]

At the moment, all actions are returning 200, so even when the request failed, the clients need to check the response body.

const save = action(async () => {
  'use server';
  try {
    return db.update()
  } catch(error) {
    return { failed: true };
  }
})

Such failed responses seem to invalidate all queries on the page also, which is wasteful.
Maybe returning custom Response should be fully supported?

const save = action(async () => {
  'use server';
  try {
    return db.update()
  } catch(error) {
    return json(null, { status: 500 });
  }
})

For the useSubmission, I would rely on what existing solutions are doing already, exposing error, failureReason

const submission = useSubmission(save);

submission.error // fetch().catch(error)

[ryansolid]

Ok let me lay the reasoning out here. Actions are meant to imitate old MPA style POST -> redirect -> GET pattern. So generally even if the POST fails it needs to show something, either by redirecting to an error page or using a Flash message. In a sense useSubmission doubles as a Flash message. And when JS is turned off it is, reading from cookies.

In so an action can only really return 2 things, the flash message and the ability to tell the browser where to go next (even if it is back at the page that instantiated the original request). So trying to figure out what HTTP codes mean in this context is tricky because generally you'd always return a redirect unless like the server crashed.

At minimum the json helper should accept revalidate key so that it can turn off revalidation. Beyond that I'm not sure.

[LexSwed]

I think I get your thinking behind actions, but I don't see how non-200 response code doesn't fit into the picture. In the end it's just a status code, the rest of the behaviour can remain the same. Otherwise it's a GraphQL approach without its tooling, so worse DX. One concrete example could be monitoring integrations, like NewRelic, which automatically gathers network activity to monitor client-server interactions. Without status codes, I need custom events to look at the response body, and it's more client code to put for something I can get "for free" from existing solution.

[ryansolid]

Ok so you don't need the HTTP codes to be accessible from the JS code just for network monitoring? Like I think the response helpers should be able to set non-200 responses. Server functions probably aren't forwarding them right now but I can change that.

[LexSwed]

Hm, didn't think about it this way, but yeah, I think this will cover the needs 👍