EventSteam! randomly seems to send line consisting of only ":"

[Connor-Kelly]

Rocket Version

0.5.1

Operating System

Arch Linux x86_64 - Linux 6.17.9-arch1-1

Rust Toolchain Version

rustc 1.94.0-nightly (f57eac1bf 2026-01-10) and 1.91.0-nightly and 1.92-stable

What happened?

for the following code:

use rocket::{
    get, launch,
    response::stream::{Event, EventStream},
    routes,
};

#[get("/")]
fn hello() -> EventStream![Event] {
    EventStream! {
        for _ in 1..5 {
            yield Event::empty();
        }
    }
}

#[launch]
fn rocket() -> _ {
    rocket::build().mount("/", routes![hello])
}

mod test {
    #[test]
    fn hello() {
        let body = reqwest::blocking::get("http://localhost:8000")
            .unwrap()
            .text()
            .unwrap();
        dbg!(&body);
        assert!(!body.lines().any(|line| { line == ":" }));
    }
}

Hitting that running server with curl returns this

$ curl localhost:8000
data:

data:

data:
:         # <- This line should not appear.

data:

While testing, this appears to happen randomly about 1/4 requests and the line moves around in order.
Could this be some sort of race condition?
From the testing, I couldnt get the regular client to replicate / fail the behavior after upgrading from 1.91-nightly ->1.94-nightly, however, the test case is descriptive of what I am seeing.

Test Case

#[test]
    fn hello() {
        let body = reqwest::blocking::get("http://localhost:8000")
            .unwrap()
            .text()
            .unwrap();
        dbg!(&body);
        assert!(!body.lines().any(|line| { line == ":" }));
    }

Log Output

> ROCKET_LOG_LEVEL=debug cargo t
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.10s
     Running unittests src/main.rs (target/debug/deps/RocketReport-8841bb1fb98f1283)

running 1 test
test test::hello ... FAILED

failures:

---- test::hello stdout ----
[src/main.rs:29:9] &body = "data:\n\ndata:\n:\n\ndata:\n\ndata:\n\n"

thread 'test::hello' (43235) panicked at src/main.rs:30:9:
assertion failed: !body.lines().any(|line| { line == ":" })
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    test::hello

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.07s

error: test failed, to rerun pass `--bin RocketReport`

Additional Context

This looks to me to be a race condition on the EventStream! that I was using to serve SSE with Datastar, this is breaking, so I made a quick helper on my end to serve with the TextStream!, which appears to fix the problem.

System Checks

• My bug report relates to functionality.
• I have tested against the latest Rocket release or a recent git commit.
• I have tested against the latest stable rustc toolchain.
• I was unable to find this issue previously reported.

[DavidSkrundz]

This looks a lot like the heartbeat: https://api.rocket.rs/v0.5/rocket/response/stream/struct.EventStream#method.heartbeat

[Connor-Kelly]

I see, so then it looks like the heartbeat is interrupting the event's write to the stream?

I'd expect that each event would look like this

data:

And from the sse spec I found (https://html.spec.whatwg.org/dev/server-sent-events.html#the-event-stream-format), the empty comment should look like:

:

(Ie a colon with two new lines after it)
However, I'm getting:

data:
:

Which I think should be:

data:

:

[martynp]

I think your last example is wrong as an empty line after the colon would indicate a double-dispatch, but no data on the second dispatch. So the ideal would be:

data:

:
data:

But it does depend on the timing, and the heartbeat could be used to also trigger the dispatch. In which case sending :<new line><new line> would work.

Will have a dig.

[Connor-Kelly]

@martynp Yep, I think you might be right now that I read through that spec some more. I think that having a single dispatch for just the heartbeat / comment might be a decent decision, but probably a design decision for the rocket maintainers.
Imo, it feels like the heartbeat should be off by default, but that's only because I didn't know where it was coming from to start with.

My main concern was that it seemed like the sse dispatches I had seemed to have inconsistent parsing / cause the Firefox devtools network to fail randomly, which I assumed coincided with the heartbeat send (after hitting the endpoint and seeing the colon lines show up).

Whenever I get a chance, I'll test and see if that is for sure the case, since it looks like the existing behavior is probably valid.