EEZ Studio CollectStream: Verify Whether Data Outputs Are Chunks or Accumulated Text

Before connecting EEZ Studio CollectStream to a string accumulator, establish what each data output contains. The official description and the inspected implementation disagree on a detail that directly changes the consumer: cumulative text versus the latest chunk.

The CollectStream documentation describes repeated outputs containing the concatenation accumulated so far. However, stream.tsx at editor commit 3000161d09d40a5c1dc2477ddc30b38037b3a612 registers a data handler that forwards data.toString() directly. That handler contains no accumulator.

This is a version-scoped discrepancy, not an executed failure report or a claim that every EEZ release behaves the same way. The pinned source corresponds to the inspected v0.29.0 editor. An installed Dashboard must be checked before choosing a consumer policy.

Two valid-looking consumers can produce opposite errors

Suppose a controlled source produces the ASCII chunks A and B. Under a cumulative-output contract, the consumer would observe A followed by AB. Under a per-chunk contract, it would observe A followed by B.

A consumer that replaces its display with each output produces the full text under the first contract, but only the final chunk under the second. A consumer that appends each output produces AB under the second contract, but AAB under the first. Both implementations can look correct when the test source produces only one chunk.

That is why “the console printed the expected text once” is not a sufficient test. The diagnostic must force or observe multiple distinct data events and preserve the individual outputs before applying any concatenation.

Identify the actual implementation first

Record the EEZ Studio build used by the Dashboard and, where available, the source revision that supplies its action implementation. The documentation page's current update date is not evidence that the installed program uses exactly the same semantics.

For the pinned source, the relevant facts are straightforward: the action accepts a Readable or Duplex instance, subscribes to its data event, converts each received item to text and propagates that text. There is no string variable in that handler that retains earlier chunks for the next output.

Do not extend that observation into claims about every upstream producer. A source may emit one large chunk or many small ones, and its chunk boundaries may change with buffering. The consumer should rely on an established representation contract rather than accidentally treating one particular producer's convenient chunking as an API guarantee.

Keep completion separate from accumulation

The inspected component subscribes the same completion handler to end and close. A local isDone guard prevents that handler from propagating ordinary completion more than once for that activation. The handler also ends the component's asynchronous execution.

This does not introduce an accumulated final-text output. A consumer that needs a complete result must construct or retain it according to the data semantics it actually observed, then use the supported completion path to decide when that collection is finished.

Do not infer detailed error recovery or a complete stream-framing protocol from the end/close guard. The cited function alone is not a guarantee that a truncated transfer is a valid application message. A protocol length, delimiter or integrity rule still belongs to the source's application contract.

Use a tiny raw-output probe

Create a disposable Dashboard fixture with a controlled readable source that emits two or three unmistakable ASCII segments. ASCII keeps the first experiment focused on accumulation rather than multibyte decoding. Arrange the diagnostic consumer to record each data output as a separate numbered entry.

Inspect that raw sequence before changing the application's text variable. If it is A, AB, ABC, a replace-with-latest policy matches that observed cumulative representation. If it is A, B, C, a once-per-chunk append policy matches that observed representation. Other output boundaries should be investigated rather than forced into a preferred explanation.

Then verify the resulting complete text and its completion event. Repeat with an empty source and with the source ending after a single segment. These cases establish how the application represents no content and whether its result from an earlier activation is incorrectly retained.

No such fixture was executed here. The examples illustrate alternative traces, not measured output from an installed EEZ build.

Make the chosen policy explicit

Name the consumer state so its purpose is clear, such as assembledText for a chunk accumulator or latestCumulativeText for a replacement value. Initialize it at the beginning of a new collection, and keep the collection identity separate if more than one source can be active.

When upgrading the editor or runtime, rerun the small representation probe before accepting the existing consumer unchanged. This is one case where blindly following either a component name or a documentation sentence can produce a plausible but incorrect application. The useful acceptance evidence is the raw output sequence from the installed implementation and the consumer policy selected to match it.