EEZ Studio CSVStringify Completion: Trigger File Writes from the Result Output
A CSVStringify sequence wire is not sufficient evidence that the CSV string is ready. In the pinned EEZ Studio Dashboard implementation, seqout is propagated after initiating serialization, while result is emitted inside the serializer's callback.
A FileWrite action started from seqout can therefore run without the new CSV result. If its content input or bound variable retains an earlier string, the symptom may be an apparently successful file containing old data rather than an obvious missing-value error.
The EEZ CSVStringify reference describes the serialization properties. The relevant ordering is in csv.ts at editor commit 3000161d09d40a5c1dc2477ddc30b38037b3a612. This is EEZ Studio v0.29.0 Dashboard source analysis; no serialization or file-write experiment was run.
Follow the callback, not the vertical order of the boxes
The execute function evaluates Input and Delimiter, obtains the header and quoted options, and starts asynchronous execution. It calls stringify with the input, options and a callback.
The callback ends asynchronous execution. If it receives an error, it reports that error and returns. Otherwise it emits the resulting string through result. The separate call to propagateValueThroughSeqout is after the initial stringify call, outside the callback.
The serializer's callback API documentation identifies that callback as the place where the output string or error is delivered. Merely arranging the CSVStringify and FileWrite boxes from left to right does not move result production into the outer sequence path.
The inspected EEZ dependency manifest pins csv-stringify 6.5.1. Record the installed dependency and editor versions when reproducing ordering, rather than assuming every implementation sharing the action name has the same behavior.
Require the current result before writing
Design the write branch around the delivery of the result string. The writer needs both its destination and the data produced by this serialization, but the serialization's outer seqout should not be used as a substitute for that data-ready event.
In a small diagnostic Flow, connect result to a receiver that records the string before forwarding it to the write operation. Keep the outer sequence continuation on a separate observation branch. This makes the two milestones visible without relying on a global latestCsv variable.
If the project intentionally stores the result first, make the assignment and subsequent write part of the result-driven branch. Do not start a separate seqout-driven writer that races with that assignment. An old valid string is especially misleading because ordinary type checks cannot distinguish it from the new valid string.
Prevent overlapping serialization requests in the first fixture. Once one request is correct, the application can define how concurrent exports are identified and paired with filenames. Concurrency should not be used to explain a stale result before the basic callback boundary has been established.
The error path must not leave a successful-looking export
A callback error produces no result through the success branch. The outer seqout may already have continued. Any UI state that declares export success solely because it received that sequence is therefore using the wrong milestone.
Track serialization success separately from file-write success. Receiving the result proves that the callback delivered a string. It does not prove that a later write reached the intended path or persisted a complete report.
For the failure fixture, use an input known to be rejected by the serializer version under test, and replace the writer with a diagnostic sink. Verify that no success-path write request is produced. Do not overwrite a real report merely to test this branch.
A three-marker trace reveals the ordering
Use two successive record lists with unmistakably different content, such as run labels FIRST and SECOND. For each request, record entry into CSVStringify, reception of seqout and reception of result. Capture the actual result string, not only its length.
The acceptance condition is that the write branch receives the matching result event before it starts, regardless of when outer continuation occurs. Repeat with an empty supported input and a rejected input so that fast success and failure do not accidentally bypass the intended routing.
The source establishes why the callback boundary matters. An installed-build trace can establish its actual scheduling. Keeping those two forms of evidence separate avoids turning an unmeasured timing assumption into a file-export guarantee.
