BUG: The client-side include carries an empty session id

[jwrosewell]

What happens

The client-side include the rust web integration serves carries an empty
session id, so fod.sessionId is an empty string in the browser. The
detection itself works and the page renders real results, so nothing is
visibly broken, but anything that needs to tell one request's include
from the next has nothing to go on.

Why it happens

Two halves disagree about where the session id lives.

SequenceElement::process in
pipeline-engines-fiftyone/src/sequence_element.rs
reads the session id from evidence and, when there is none, creates a
fresh one with Self::new_session_id(). It then stores that value in
its own element data through data.get_or_add(Self::KEY, ...), and
SequenceData::session_id() at
line 77 is the
accessor for it. Nothing writes the value back into evidence.

JavaScriptBuilderElement::session_id in
javascript-builder/src/element.rs
reads only evidence:

fn session_id(data: &FlowData) -> String {
    data.evidence()
        .get(EVIDENCE_SESSIONID)
        .unwrap_or("")
        .to_owned()
}

On a first request there is no query.session-id evidence, because the
browser has not been given one yet, so the builder reads an empty string
and renders var sessionId = ""; into the include. The freshly created
id sits in the sequence element's data where the builder never looks.

The sequence number does not have this problem, because the JSON builder
reads it from evidence too but the client posts it back on later
requests, so it works from the second round trip onward. The session id
never recovers, since the empty value is what the client is given in the
first place.

How it was found

The shared browser contract suite
(51Degrees/selenium-api-tests)
has a SessionStorageCache_Chrome test that compares the session id
across two pages to prove the include was fetched fresh rather than
served from the browser cache. Run locally against the rust example on
30 August 2026 it stops with:

Assert.Inconclusive: The 'rust' example serves an include with no session id,
so whether it was re-fetched cannot be determined (page 1 '', page 2 '').

The suite skips rather than fails, so this does not turn CI red today. It
does mean that test can never pass for rust, and it will keep skipping
until the session id is populated.

I confirmed the empty value directly, by running
dd-web-getting-started-cloud against the live cloud and reading the
sessionId the include carries.

Suggested fix

Either the sequence element writes the id it creates back into evidence
under EVIDENCE_SESSIONID, so every later element sees it, or the
JavaScript builder falls back to SequenceData::session_id() when the
evidence is absent. Writing it back to evidence looks the better of the
two, because the JSON builder and anything else added later then get the
same value without each needing its own fallback, but that is a judgement
for whoever picks this up.

Whichever way it goes, a test should assert that a request carrying no
query.session-id evidence still produces an include with a non-empty
session id, and that a request carrying one keeps the value it was given
rather than replacing it.

Not in scope of the open pull requests

This is separate from
pull request 21 and
pull request 22 and should
not be folded into either.

Written with AI assistance under James Rosewell's direction and needs
human review.