fix: register the time-series progress listener before the blocking call

[jcschaff]

Follow-up to #2063, from looking into the commented-out handlers in TimeSeriesDataJobListener.

The commented-out code is fine — leave it

1c16cce796 (2018-03-27, "simplify DataJobEvent:complete, getTimeSeriesValues() rpc blocks")
deliberately removed the results and the exception from DataJobEvent: "the COMPLETE and FAILURE
events no longer hold the results and the exception (instead managed by the invoking process of
the rpc call)". DataJobEvent today carries only eventType, progress, dataKey,
dataIdString, vcDataJobID — there is nothing left for those two handlers to write, and
restoring them would not compile. No change here.

But that commit left the registration in the wrong place

It made getTimeSeriesValues() blocking and disabled the polling loop, without moving the
listener registration:

TimeSeriesJobResults results = myPDEDataContext.getTimeSeriesValues(spec);  // blocks
hashTable.put(StringKey_timeSeriesJobResults, results);
djl = new TimeSeriesDataJobListener(...);        // registered only AFTER the work is done
dataJobListenerHolder.addDataJobListener(djl);   // ...and removed in finally

So the one handler still live — DATA_PROGRESS — could never fire:

• DataSetControllerImpl fires DATA_PROGRESS from five sites during the computation, with a real percentage
• gated on vcDataJobID.isBackgroundTask(), which these jobs always are — the callers assert it
• the only TimeSeriesDataJobListener construction in the codebase is that line, after the rpc
• the delivery path is live: PDEDataViewer.dataJobMessage fans out to dataJobListenerList

The progress was computed server-side, serialised, shipped to the client and dropped on arrival.
The user got a task dialog that never advanced during exactly the long retrievals #2063 was
about — that reporter was pulling a time plot from a still-running simulation.

The fix

Move the two lines above the call. The existing finally already removes the listener, and the
listener only touches ClientTaskStatusSupport (its hashTable field is dead now), so there is
nothing else to reorder and no new threading concern.

Tests

One test added to TimeSeriesDataRetrievalTaskTest: the stub context records whether the
listener was registered at the moment the retrieval ran. Checked against the old ordering — it
fails there and passes here, so it pins the ordering rather than just passing.

vcell-client Fast: 37 tests, 0 failures, 0 errors.

Deliberately not included

That 2018 commit named "remove the .isBackgroundTask mode" as the next step, and it is the
switch gating these events. That is a larger change and a design call, so it is untouched here,
as are the stale commented block and the now-unused hashTable field on the listener.

🤖 Generated with Claude Code

https://claude.ai/code/session_01D71LBYmQNf5J94wPqr81Jx