[jwrosewell]

The JavaScript Builder Element takes the session id and the sequence from the Sequence Element's data, as step 5 of the specification says, so a pipeline with no Sequence Element always renders the defaults.

This draft was stacked on #80, which has merged into rc. Commit 11b5eb4 merges rc at ddb7d04, a807668 merges it at a2d6cdd with #88, which changes JavaScriptBuilderElement.java at other lines, and 0866a0c merges it at 528e0df with #108, each with no conflict, so the diff against rc is this change alone. The merge had one conflict, in SequenceElement.getElementDataKey, where rc returns the literal "sequence" and this draft returns its constant, now DEFAULT_ELEMENT_DATA_KEY, which holds the same text, and the constant is kept.

The problem

Process in javascript-builder.md, at commit 67ead698 on specifications rc, step 5:

Retrieve the Element Data for Sequence Element from the Flow Data. This contains the session id and sequence number to be passed to the template. Where there is no Sequence Element, the sequence MUST be rendered as 1 and the session id as an empty string, so the script always parses.

On rc, JavaScriptBuilderElement.getSessionId and getSequence read the Evidence instead, query.session-id and query.sequence. With a Sequence Element in the pipeline the two sources agree, because that element writes both to Evidence as well as to its own data, so nothing changes. With no Sequence Element they do not agree, because a request can carry either value itself. A page calling the JSON endpoint with ?session-id=abc-123&sequence=7 had both written into the script, where the specification asks for an empty id and 1.

What changes

• getSessionId and getSequence take their value from the Sequence Element's Element Data, under the key sequence, which one new getSequenceData reads once per request. When the Flow Data holds nothing under that key, which is what a pipeline with no Sequence Element gives, the session id is empty and the sequence is 1.
• FlowData.get(String) throws NoSuchElementException when the Flow Data holds nothing under the key, whatever its documentation says, so getSequenceData checks getDataKeys() first.
• SequenceElement gains DEFAULT_ELEMENT_DATA_KEY, the constant getElementDataKey already returned, so the builder names the same key rather than repeating the text.
• The checks on each value are unchanged. A sequence that is not a positive 32 bit integer still gives 1, and a session id that does not match [A-Za-z0-9-]{1,64} still gives an empty string, because both are written into the script as code.
• EXCLUDED_PARAMETERS still leaves query.session-id and query.sequence out of the parameters object, which the same section asks for, and the element's own accepted Evidence is unchanged.

Behaviour that changes for callers

A pipeline that has the JavaScript Builder Element and no Sequence Element renders an empty session id and a sequence of 1, whatever the request carried. The script then always sends sequence 1 on its callbacks and keeps no session, which is what the specification asks for, because without a Sequence Element nothing counts the callbacks. Adding a Sequence Element restores the counting, and the 51Degrees web integration adds one already, so a site using it is unaffected. This belongs in the release note.

Review fix (commit 64a2685). The Sequence Element's new key constant is named DEFAULT_ELEMENT_DATA_KEY, as .NET names its own, and its Javadoc says a subclass can give another key from getElementDataKey(), because the name ELEMENT_DATA_KEY read as the only key there could be. The constant is new in this draft, so nothing else used the old name.

A test the change affects (commit c771241). The first full build of the merge (run 43072025592) failed JavaScriptBuilderTests.JavaScriptBuilderElement_VerifySession, "JavaScript does not contain expected session id", because the test's mocked Flow Data held the session id only in the Evidence. The mock now holds the Sequence Element's data as well, with the same session id and sequence, as a web integration's pipeline does. The same test needed the same change in .NET.

How it was checked

The tests were written first and fail on the branch without the change.

SessionIdAndSequenceTests gains a stand in for the Sequence Element that writes the two values straight into the Element Data, so the rule on each value is still tested, and a value the real element would never write can be tried as well. The new NoSequenceElement_WithEvidence_DefaultsRendered builds a pipeline with no Sequence Element, adds a session id of abc-123 and a sequence of 7 to the Evidence, and expects an empty id and 1.

Run	Link	Result
Red	run 42933296674	The tests without the change. On Java 8 and 21, 7 of 33 fail, being the new test, the two valid session id tests and the four valid sequence rows, because the old code reads the Evidence and the stand in writes only the Element Data
Green	run 42934217619	Head adb1bdd. On Java 8 and 21, all 33 pass, with 13 SequenceElementTests
Green, after the rc merges and the rename	run 43029583325	Head 64a2685. On Java 8 and 21, all 33 SessionIdAndSequenceTests and 13 SequenceElementTests pass
Green, with the mock holding the Sequence Element's data	run 43079207237	Head c771241. On Java 8 and 21, all 33 SessionIdAndSequenceTests, 13 SequenceElementTests and 15 JavaScriptBuilderTests pass
Full pull request build	run 43080258753	Head c771241. All 9 jobs without macOS passed, being Ubuntu Java 8, 11, 17 and 21, Ubuntu ARM Java 17, and Windows Java 8, 11, 17 and 21. Every Setting 'PullRequestSha' line, in Configure and in each of the 9 jobs, is c771241, and Configure printed "Left out 6 macOS entries"

macOS was left out of this draft's full build under the 9 November decision. The rc head is built with macOS before it merges into main.

Every exit path of getSessionId, getSequence, getSequenceData and getSequenceValue was read after the change.

Other open drafts

#80, on which this draft was stacked, merged into rc on 11 November 2026, so nothing else has to merge first.

What remains

The JSON Builder Element still reads the sequence from the Evidence. json-builder.md asks for its own behaviour there and is not changed by this draft.

Version

Patch only.