Disable mujs on error 5xx

[Tobi-De]

Hello, I hope you are doing great, nice lib.
I currently have mujs setup in a django project of mine, minor inconvenience is that mujs basically swallow 5XX responses, unless I look at my terminal I can't tell when a 5xx happened, the page just seems to do nothing. What would be the idiomatic way to fix this ?

[Dietr1ch]

(Non an answer)

Just to throw ideas on how to behave here,

• HTMX Offers to swap the response into different elements,
  • Server errors hx-target-5*="#serious-errors"
  • Not found hx-target-404=#not-found
  • Catch all hx-target-*=#contents
  • https://htmx.org/extensions/response-targets/

I guess that proper self-healing behaviour would be to retry ephemeral errors and to allow surfacing errors (after retrying if needed) in some error-specific target element.

---

This is kind of off-topic

On HTMX 4 they changed how Not Modified (304) behaves and they started swapping in an empty response, which effectively empties the target element. I think it's literally correct, but on a more friendly take, obviously the wrong thing to do. I don't think this is on-topic enough, but the behaviour for empty body 304s should be clear too.

• [HTMX4] Swapping cached responses bigskysoftware/htmx#3675

[Amaury]

Thanks, glad you like it!

µJS fires a mu:fetch-error event on HTTP errors (including 5xx), but deliberately does not render the error response. This is by design: error pages often have a different layout, and injecting them into the current DOM could produce broken results.

You can listen to this event to handle errors however you want. For example, if you want the browser to display the server's error page natively:

document.addEventListener("mu:fetch-error", function(e) {
    window.location = e.detail.url;
});

This forces a full page load on error, letting Django's error page render normally. You could also display a notification, log the error, or show a custom message depending on e.detail.status.

That said, I'm open to suggestions if you think there's a simpler way to handle this. Feel free to open a discussion so we can explore ideas together before any code is written.

[Tobi-De]

I think this is a solid solution. It’s flexible enough to let users implement the strategy that works best for them, and honestly, a full reload is exactly the approach I’d take here. Thanks again.