eduKate Singapore

VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

Next useful routeCanonical hubHELP

How Superintelligence Works | Agent Server-Sent Events — Last-Event-ID, Reconnects and Verified Completion

—

by

eduKate Asia

Did you know? A live AI stream may reconnect and show an old event twice. Server-Sent Events are excellent for progress, but trustworthy completion still requires a durable, verified result.

Quick answer: parse real SSE frames, attach meaningful scoped event IDs, handle Last-Event-ID recovery and replay, deduplicate old events, enforce authorization on each connection, and distinguish interim text from committed outcomes.

This chapter continues How Super Intelligence Works. Its school and numeric cases are fictional teaching examples, not measurements of an eduKate service.

Contents and reader pathways

1. The short answer: a live stream is not the final outcome

Did you know? A streaming AI assistant can show twenty lines of a useful reply and still fail before its final instruction reaches the reader. A progress message describes what a server emitted, not automatically what the browser received, saved or approved. If the network drops after an external write, the next connection may display a repeated success event or lose the receipt entirely.

Server-Sent Events, often abbreviated SSE, offers a simple way for servers to deliver an ordered stream of text events to a browser over HTTP. Its value is responsiveness: the reader can see task progress, interim evidence and eventually a final state without continuously refreshing the page. Its limit is equally important: the connection is a transport, not a database transaction or independent proof of a completed external action.

The safe pattern is to give each logical job a stable identity, emit typed events with a meaningful cursor, resume according to the server’s documented retention contract, deduplicate repeated event IDs and use an authoritative status endpoint or durable result record before marking an action complete. This chapter develops those distinctions using fictional educational workflows. It describes existing web technology, not proof that artificial superintelligence already exists.

2. What EventSource actually does

In a browser, the EventSource interface opens a long-running HTTP connection to a server endpoint whose response uses the MIME type text/event-stream. The client receives messages as events and can listen for the default message type or for named event types specified by the server. Because the transport is one-way from server to client, it is well suited to displaying progress but not a substitute for sending commands in both directions.

A school tutoring dashboard might start a report job through an ordinary authenticated POST, receive a job ID, and then use EventSource to watch progress for that job. That division prevents a reconnect from inadvertently repeating the action that created the report. The progress connection answers ‘what has happened to job J?’ rather than ‘please start job J again.’ The workflow must separately protect the creation operation against duplicate POST submissions.

Read the MDN guide to using Server-Sent Events for browser examples, and the WHATWG HTML Standard’s server-sent events section for event-stream processing and reconnection rules. A custom client may implement an SSE-like protocol differently; do not assume browser behavior automatically applies to every library.

3. The event-stream format uses lines, not arbitrary JSON chunks

An SSE response contains fields separated by line endings. Common fields include data, event, id and retry; a blank line dispatches a completed event when appropriate. Lines starting with a colon are comments and are often used as keep-alive messages. Data can span multiple data lines, which the parser joins with newline characters. A custom consumer that parses each incoming network chunk as a full JSON object will eventually mis-handle split messages.

Network reads can divide a single field in half or combine several complete events in one buffer. HTTP chunk boundaries do not define semantic event boundaries. If an AI client counts one socket read as one complete model response, a slow or busy network can produce malformed data or lost updates even when the server emitted perfectly valid SSE framing.

The format is decoded as UTF-8 under the HTML Standard. Test with non-ASCII learner names, mathematical symbols and multilingual lesson titles, but avoid using personal student data in public test fixtures. A strict parser should follow the documented line and field rules, including its handling of comments, unknown fields, empty values and the final dispatch boundary.

4. Named events make progress easier to understand

Without a named event field, the browser dispatches an ordinary message event. With an event field, the sender can distinguish progress, warning, draft, approval-required and complete messages. The server and client should agree on the allowed event types and their schemas. A label such as complete should not be accepted simply because untrusted text inside the data field says ‘I finished.’

For example, a fictional reporting pipeline could emit event: queued with a job ID, then event: extracting with a source version, then event: draft_ready with a preview reference, and finally event: verified_complete with a destination receipt. The consumer should validate every event’s job identity and payload before updating the interface. Unknown types should not be silently treated as approval or success.

Typed events also improve accessibility and debugging. A reader may prefer a concise ‘three sources checked, one still pending’ indicator instead of watching every token of a generated paragraph. Rate-limit purely visual progress so screen-reader users are not overwhelmed. The semantic meaning of a server event should come from the authenticated protocol, not from how convincingly a language model narrates it.

5. An id field can anchor reconnection

When an event carries an id field, a browser EventSource remembers the event ID string. After an interrupted connection, it can send that value in the Last-Event-ID request header during reconnection. The server may use this hint to choose what to replay or resume. The HTML Standard defines the browser behavior; it does not guarantee that every application server stores durable history for all past IDs.

An identifier is meaningful only within the scope the service specifies. An ID might be a per-job sequence number, an opaque cursor or a globally ordered log token. Two jobs can both emit ’42’ without representing the same event. An agent should bind every received ID to the authenticated stream, job and version, rather than comparing bare strings across unrelated data sources.

The application must define what happens when a resume cursor is too old, unknown or associated with a different account. A safe implementation may return an explicit reset state and direct the client to an authenticated snapshot. It should not pretend that starting from the newest live event reconstructs the history that disappeared during the disconnection.

6. A blank id and invalid id characters matter

The HTML Standard treats an id field containing a valid value as an update to the last event ID buffer. An empty id value can reset that buffer, changing what will be sent on a later reconnect. A value containing a NULL character is ignored by the relevant parsing rule. Developers sometimes overlook these details because most happy-path examples use simple increasing numbers.

If an intermediary strips or changes id lines, the client may resume from the wrong place. If a server emits the same ID for different logical events, a client may suppress a meaningful update as a duplicate. Do not assume that an EventSource cursor has cryptographic integrity or that an arbitrary ID can authorize access to another user’s event stream.

Validate identifiers on the server and enforce their scope. A cursor is a position hint, not an authentication credential. The browser’s reconnect request still needs the appropriate origin, session and permission checks. If the user’s access is revoked while the stream is open, the server must stop protected delivery rather than treating the last event ID as permanent access.

7. The retry field measures milliseconds

An SSE retry field can instruct a browser about a reconnection delay, expressed as an integer number of milliseconds. A non-integer value does not update the reconnect time under the standard. This is different from an HTTP Retry-After response header, which has its own semantics and syntax. Confusing those two controls can produce a storm of simultaneous reconnection attempts.

Suppose a fictional server sends retry: 4000. The indicated SSE reconnection interval is four seconds, not four minutes or four individual retries. The browser’s actual reconnection lifecycle and a custom client’s backoff may have additional conditions. The field does not guarantee that the server will be ready or that a job will resume successfully after that interval.

A robust service adds appropriate concurrency limits and avoids asking every disconnected user to reconnect at an extremely aggressive rate. On shared infrastructure, network failures may disconnect thousands of clients together. An agent that controls the service should preserve stable job identities and server-side capacity while making the retry behavior predictable to people who are waiting for legitimate task results.

8. A comment can keep a connection alive

Comment lines beginning with a colon are ignored as application messages by the SSE parser. Some servers emit periodic comments as heartbeats to keep intermediaries from treating a quiet connection as unused. A comment proves only that bytes traveled on the stream; it does not mean a document was verified, a model is still computing accurately or an external action succeeded.

Intermediaries may buffer responses or close idle connections, and runtime defaults can change how quickly an event becomes visible. When the server emits five progress messages but the browser sees them together much later, inspect proxy buffering, flushing and network behavior before blaming the language model. A correct SSE parser cannot compensate for an infrastructure path that delays every byte indefinitely.

Do not use heartbeats as a substitute for an authoritative health check of the underlying job. A web server can send keep-alives while its worker queue is stalled. Expose bounded status fields—queued, active, blocked, completed, failed or unknown—through trusted state and use heartbeats solely to maintain and observe the transport connection.

9. Partial text is not an approved final answer

Generative interfaces often stream small text fragments to reduce perceived waiting time. The user can start reading immediately, but the final paragraph may revise earlier claims, reveal an inconsistency or report that a tool call failed. Showing partial text is useful as long as its provisional nature remains clear. A progress fragment should never be treated as a signed official notice or verified answer.

Consider a fictional student report generator that streams ‘The class starts at 4—’ and then corrects it to ‘The class starts at 4:30 PM after the timetable update.’ If another system snapshots the first fragment and sends it to parents, it turns a provisional prefix into an incorrect final statement. Keep a separate committed answer version rather than using the visible text buffer as the authoritative result.

The Partial-Answer Streaming and Stream Integrity chapters develop this commit boundary. SSE adds the specific event-ID and automatic reconnection mechanisms that can cause provisional material to repeat or appear in a new connection.

10. Reconnecting may repeat events

A network interruption can happen after the browser received a message but before the application persisted that fact. On reconnection, the server may replay some prior events to avoid missing changes. Those repeated events are often a feature of durable delivery, not evidence that the underlying business task ran twice. A consumer should distinguish duplicate notification from duplicate external effect.

Maintain a per-job record of accepted event IDs or sequence ranges, depending on the server contract. On an exact repeat, do not append the same completed paragraph twice or add one more to an aggregate count. If the same event ID arrives with a different payload, surface a protocol inconsistency rather than choosing whichever copy came last without explanation.

State reconciliation is essential because exactly-once end-to-end UI delivery is not guaranteed simply by using EventSource. If a status says the report is already complete, the browser may skip replaying dozens of progress events and fetch the final signed or versioned result. That is often safer and faster than reconstructing a final state from every visible progress update.

11. An original 96-delivery example

Imagine a fictional study assistant whose stream endpoint yields 96 message deliveries across an initial connection and two reconnects. On inspection, 14 deliveries have event IDs already accepted by the browser, eight are transport heartbeats without application data, five are superseded progress snapshots, four have validation failures, and 65 are new valid application events. The arithmetic is 14 + 8 + 5 + 4 + 65 = 96.

A misleading dashboard might report 96 separate model actions. A useful report distinguishes 65 newly accepted events, 14 duplicates, eight heartbeats, five obsolete snapshots and four rejected events. Of the 65 valid events, perhaps only one carries a verified_complete outcome backed by the job store. The other 64 may be useful progress but are not 64 independent completed reports.

These values are invented teaching data, not measurements. Their purpose is to keep denominators honest. A user-facing progress indicator can say that the stream resumed and the final result was verified, but should not multiply successful work just because the transport retried old events.

12. A lost cursor requires a snapshot or a gap repair

Event servers cannot promise infinite history unless they actually retain it. An old Last-Event-ID might refer to a record removed by retention, a different deployment or a previous stream epoch. Treat such a cursor as a request to recover, not an instruction to fabricate missing messages. Depending on the business contract, the server may provide a current snapshot or an explicit gap result.

Suppose a parent dashboard last saw event 21, but the server retains events 40 onward. Restarting at event 40 without explanation can hide a changed lesson time between 21 and 40. A trustworthy interface fetches the current timetable from its authoritative database and marks historical progress unavailable if necessary. Present state and full audit history are separate deliverables.

If exact history is required for compliance, the application needs durable event storage and documented retention independent of SSE. Browser reconnection does not create that store. A model may summarize surviving events, but it must not invent the missing stretch of activity or claim that an absent event can be reconstructed from its neighboring messages.

13. Security is separate from the stream cursor

An EventSource URL may refer to a student’s report, an employee’s workflow or another sensitive stream. The server must authenticate the request and authorize the specific resource on initial connection and after reconnection. A Last-Event-ID sent by the browser is not a secret or proof of account ownership. An attacker may guess or copy it; the server must still enforce the current permission boundary.

The browser EventSource constructor exposes a URL and a withCredentials option for cross-origin requests; it is not a general-purpose interface for attaching arbitrary custom request headers. Design session or token handling accordingly, following same-origin policies, HTTPS and controlled CORS settings. Do not put long-lived bearer secrets into publicly logged query strings merely to work around API limitations.

Cross-origin credentials require the destination’s deliberate policy, not a wildcard access-control shortcut. The Agent CORS Decisions and Session Cookies chapters explain the adjacent authorization boundaries. Live status still needs resource-specific access checks.

14. SSE is not WebSocket, nor an HTTP POST

SSE sends server-originated text events to a client over an HTTP response. WebSocket supports two-way messages with a different connection protocol. Neither inherently offers durable exactly-once external side effects. A standard HTTP request can create a job, while SSE reports changes to that job; mixing creation into a reconnecting stream can make an innocent network repair start the job again.

Choose based on the interaction. A report progress bar or public status feed may work well over SSE. A highly interactive collaboration surface with bidirectional low-latency updates may require another transport. Even then, stable identities and verified state are needed. Do not select a fashionable transport before defining what the reader needs to know and what the sender can prove.

An agent explaining the difference should avoid suggesting that SSE automatically makes every streaming API reliable or that WebSocket always preserves causal event order across restarts. Transport ordering within one live connection does not imply a persistent history through crashes. The application’s storage, reconnection and permissions policies provide the missing guarantees.

15. One connection is not one durable job

A progress connection can disappear when a student locks their phone, changes network or closes the browser. The underlying authorized job may continue on the server. If the job’s lifetime is independent of the connection, store its state in a durable service and let the browser reconnect later. The user interface should not quietly create a second job because its display stream restarted.

Conversely, some streaming generators intentionally stop computing when the client disconnects. The server must document this behavior and determine whether any already committed external effects remain. An ordinary client cannot infer cancellation solely because the EventSource closed. Reporting a confirmed cancellation requires an appropriate server-side receipt.

For a long-running educational report, design a stable job ID and a status endpoint so the user can return after closing the tab. A final answer can be fetched from durable state, while SSE provides optional live progress. This separation also makes accessibility, mobile interruptions and support investigations easier.

16. Backpressure and many open connections

An SSE connection can deliver events faster than the browser or application can use them. The display may lag, memory may grow and redundant progress events may accumulate. For fast-changing telemetry, consider emitting aggregate snapshots at sensible intervals instead of every internal step. Completion events and significant warnings should not be discarded as casually as cosmetic progress counters.

Browser and proxy connection limits are affected by HTTP versions, network configuration and shared origins. A large dashboard with many independently opened streams can waste connections and complicate recovery. Where useful, share one authenticated job-status feed or multiplex application event types within a documented server contract. Avoid a design that asks each table row to maintain its own permanent stream.

Measure queue depth, time from emission to display, reconnect rate and last acknowledged event ID. A healthy dashboard should not infer that the model is intelligent merely because it streams at high speed. Human readers need a comprehensible final answer and a clear status, not an endless flood of provisional tokens.

17. An outcome ledger for external actions

Consider a fictional AI agent that uses SSE while creating a private lesson-plan document. It emits progress: draft generated, progress: awaiting approval and progress: submitting. The content-management system returns an identifier, but the network to the agent’s browser drops before the complete event is displayed. The browser reconnects and sees the older submitting event again.

A bad implementation retries document creation because no complete event appeared on the screen. A safer implementation queries the destination with the stable operation ID or expected slug, verifies the document and its current revision, then emits a new receipt-backed complete snapshot to the reconnected client. The progress stream is repaired by reading reality, not by repeating the last command.

This is the same principle developed in Agent Long-Running Operations. An HTTP 202 acknowledgement, a streaming progress update and a final destination receipt describe different states. Only the last can establish the specific effect actually recorded by that system.

18. Design a small status state machine

A useful job model might include created, queued, running, awaiting_authorization, committed, failed, cancelled and outcome_unknown. The names matter less than the documented transitions. An SSE event should announce an observation of one of those states, while a separate authoritative job store governs the transitions and retains the final result. Do not let arbitrary browser data instruct the server to declare success.

When an event arrives out of sequence, compare it with the current resource version. A stale running event must not downgrade a committed result. An error event after a real commit may describe transport failure, not a failed business action. If the stream sends two incompatible terminal outcomes, stop automatic interpretation and reconcile the job with the destination.

The model can assist by explaining the state to a parent or operator, but it must not transform ‘no proof of success’ into ‘proof of failure.’ Unknown outcomes deserve a clearly labeled status and a specific repair route. This is the difference between persuasive text and dependable automation.

19. A changed-context worked example: homework submissions

A fictional school portal receives a homework submission and starts an OCR-based preview. The server stores submission S-18, then emits events 1 through 12 showing upload verification, file parsing and preview generation. After event 9, the family tablet loses its internet connection. The preview finishes on the server at event 12 while the tablet is offline.

On reconnection, the browser supplies its last event ID when appropriate. If the server retains events 10 through 12, it can replay them. If it retains only final state, it can return a snapshot indicating that submission S-18 is accepted and preview version P-2 is available. Neither path should resubmit the assignment. The essential fact is the portal’s accepted submission record, not the delivery count of progress events.

Change one assumption: the upload was never accepted, and events 1 through 9 were only preliminary. A final status read must say submission unverified and give the user a safe retry or support path. An assistant should not claim the assignment is safely submitted simply because the earlier streaming messages sounded encouraging.

20. How to test an SSE implementation

Run tests that split a data field across multiple network reads, combine several events into one read, include multiple data lines, send UTF-8 text and send comments. Verify that blank-line dispatch and named event behavior match the standard. Test an id reset, a duplicated ID, a reconnect after a missed interval and a cursor that no longer exists on the server.

Inject a crash after the server commits a job result but before the browser sees the complete event. The next connection should recover the same result ID rather than create a new effect. Test revocation while a stream is active and verify that the service stops delivering protected events. Test an unauthenticated user who guesses a legitimate event cursor; the authorization check must still reject them.

Include a negative test for a malformed event payload and another for a network proxy that buffers output. The test report should say what was verified—framing, replay, authorization, snapshot recovery and final side-effect readback—rather than announcing generically that ‘streaming is reliable’ after one happy-path demonstration.

21. A concise debugging decision tree

If the browser receives no events, confirm the endpoint’s response MIME type, authentication, server flush behavior and proxy configuration. If messages arrive only in large bursts, inspect buffering rather than assuming the model paused. If duplicate text appears after reconnection, check event-ID deduplication and whether the UI is appending snapshots as if they were deltas.

If the browser appears stuck in reconnects, check network failures, service capacity, the retry interval and whether the endpoint intentionally instructed a terminal stop. If some events are missing, inspect retention and Last-Event-ID handling. If the page displays complete but the document is absent, inspect the underlying job store and CMS receipt; an SSE label is not proof of a write.

Record non-sensitive correlation IDs, event types, cursor scope, actual job state and final destination identifiers. Do not log bearer tokens or private student messages merely to make troubleshooting easier. A good support response explains what is known and what remains uncertain without exposing irrelevant data.

22. Six quick questions and checked answers

Question one: is SSE bidirectional like WebSocket? No; standard EventSource receives server-originated messages. Question two: does an id automatically guarantee infinite replay? No; the server must provide retention and recovery. Question three: does retry: 4000 mean four seconds? Yes, under the SSE field’s millisecond interpretation.

Question four: is a comment heartbeat evidence that a report was published? No. Question five: can the browser reconnect and display the same event again? Yes, depending on the server’s replay contract, so handlers must be duplicate-safe. Question six: should a restarted display issue a new create request just to obtain progress? No, unless the user actually intends a new operation; it should usually follow the original job identity.

An advanced question: the UI saw a submitted event, the connection dropped and the backend job is now marked unknown. What evidence would justify a retry? Identify the destination’s actual operation record, authorization and idempotency behavior first. The stream alone cannot answer whether the external write occurred.

23. Frequently asked questions

What does SSE stand for? Server-Sent Events, a text-event streaming mechanism from an HTTP server to a client.

What is Last-Event-ID? A reconnection request header that can carry the browser’s remembered event ID to help the server resume according to its own supported contract.

Will EventSource reconnect by itself? The browser interface includes automatic reconnection behavior under defined conditions, but availability and replay depend on the server.

Can SSE authenticate an agent request? The HTTP endpoint can use appropriate authentication and authorization; the event cursor alone is not authentication.

Are data chunks equal to messages? No. Transport chunks may split or combine SSE fields and messages. Parse the protocol framing.

Can I treat the last progress message as final? Not safely. Require a verified final job state or destination receipt.

Does a successful SSE connection guarantee job completion? No. The connection and the underlying work have separate lifecycles.

Does this mean today’s AI is superintelligent? No. These are ordinary engineering controls relevant to current AI services and hypothetical more capable systems.

24. Sources and further learning

The key references are the WHATWG HTML Standard: Server-sent events and MDN’s SSE implementation guide. They specify the wire format, parser fields, event IDs and reconnection behavior. Always test the actual runtime, reverse proxy and backend because application-specific replay guarantees are not furnished by the browser specification alone.

Continue with Agent Stream Integrity, Agent Event Ordering and Long-Running Operations. The broader reading route begins at How Super Intelligence Works.

The practical takeaway: streaming is a way to show progress, not a substitute for evidence. Keep the job identity stable, resume from a documented cursor or snapshot, treat partial text as provisional, and report completion only from the authoritative effect that readers actually depend on.

Discover more from eduKate Singapore

Subscribe now to keep reading and get access to the full archive.

Continue reading