Skip to content

Fix: default to status 200 for non-empty DatastarResponse (Litestar)#39

Open
tompassarelli wants to merge 1 commit intostarfederation:developfrom
tompassarelli:fix/litestar-response-status-200
Open

Fix: default to status 200 for non-empty DatastarResponse (Litestar)#39
tompassarelli wants to merge 1 commit intostarfederation:developfrom
tompassarelli:fix/litestar-response-status-200

Conversation

@tompassarelli
Copy link
Copy Markdown

Problem

Litestar's Stream base class defaults to status 201 when no status_code is provided. Datastar's client-side fetch action (v1.0.0-RC.8) only processes SSE responses with status 200:

// fetch.ts line 561
if (status !== 200) { dispose(); resolve(); return; }

This means every DatastarResponse with content silently fails — the browser receives the SSE stream, but Datastar discards it without processing any patch-elements or patch-signals events.

Fix

One line: default to 200 when content is present and no explicit status code is given. Same pattern already used for the empty-content 204 case.

else:
    status_code = status_code or 200  # added
    headers = {**self.default_headers, **(headers or {})}

Impact

Without this fix, every Litestar app using DatastarResponse must either:

  • Pass status_code=200 on every call
  • Subclass DatastarResponse to override the default

Both are non-obvious workarounds for what should be a sensible default.

Litestar's Stream base class defaults to status 201 when no status_code
is provided. Datastar's client-side fetch action (RC8) only processes
SSE responses with status 200 — non-200 responses are silently discarded:

    // fetch.ts line 561
    if (status !== 200) { dispose(); resolve(); return; }

The empty-content case already defaults to 204. This adds the same
pattern for the non-empty case: default to 200 when the caller doesn't
specify a status code.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant