You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fixes#2189 Batch update simulation from building block (#2276)
* Fixes#2189 Batch update simulation from building block
* #2189 Update simulations from building blocks in parallel with per-simulation status
Adds a parallel update flow with a modal showing per-simulation status
(Waiting/Updating/Pending/Updated/Faulted/Canceled):
- ParallelSimulationUpdateTask routes single-simulation updates to the existing path and
multi-simulation updates to SimulationUpdatePresenter, which configures the models off
the UI thread and applies them.
- SimulationUpdateTask.ConfigureSimulationsInParallel builds each model in parallel and
publishes SimulationConfigurationStarted/Finished events; the presenter listens and
updates each simulation's status.
- Cancel stops simulations that have not started configuring; in-progress ones finish.
Configured-but-invalid simulations are reported as Faulted (not Canceled), and the
command description counts only the simulations actually updated.
- ApplicationStartup registers the UI thread and a splash-thread-bound publisher so events
dispatch on the correct thread.
Also bumps OSPSuite.Core to 13.0.129 and OSPSuite.Utility to 5.0.0.10, and moves the shared
spec helpers (SynchronousSynchronizationContextForSpecs, ConcurrencyManagerForSpecs) into
tests/MoBi.Tests/Helpers.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Normalize CreateModelAndValidate to a single non-null result contract
ModelConstructor.CreateModelFrom never returns null - it returns an invalid
CreationResult (carrying the validation messages) when the build fails - so the
results == null branches were dead and only produced a spurious null failure
shape. Drop them so CreateModelAndValidate(throwOnInvalid: false) always returns
a non-null result and callers check IsInvalid instead of null. XML doc and the
spec mock aligned with the single contract.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Pluralize the configured-simulations command description
Use the OSPSuite.Core PluralizeIf string extension so the command-history
description reads "Configured 1 simulation" / "Configured 2 simulations"
instead of always pluralizing.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Always emit a terminal configuration event with the correct outcome
Replace SimulationConfigurationFinishedEvent with distinct
SimulationConfigurationSucceededEvent / SimulationConfigurationFailedEvent and
publish one from a finally block, choosing by result validity. A started row now
always reaches a terminal state, and an invalid result shows Faulted instead of
the misleading Pending it showed when only a single "finished" event was raised.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Drop the redundant manual listener teardown from SimulationUpdatePresenter
The presenter is registered as a listener automatically by the
EventRegisterFacility when the container resolves it, and the EventPublisher
holds listeners by weak reference and prunes dead ones on each publish. The
explicit RemoveListener in Cleanup was therefore unnecessary for this
short-lived modal presenter (only long-lived shell presenters need it). Removing
it also makes the IEventPublisher dependency dead, so drop it and the Cleanup
override entirely.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Guard against a null command from ConfigureSimulation
_heavyWorkManager.Start swallows exceptions thrown by its action, so when the
model build fails the captured command stays null and would flow into
AddToHistory(null). Fall back to a MoBiEmptyCommand, matching the existing
guards in this method.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Always complete the update dialog even if the configuration task faults
The ContinueWith dereferenced configurationTask.Result directly, so a faulted
task would throw inside the continuation, skip applyConfigurations, and leave the
modal stuck because _view.ShowCompleted() never ran. Pass the task instead and
apply results only when it ran to completion, keeping ShowCompleted in the
finally so the dialog always closes.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Keep successfully configured simulations when the batch hits an unexpected error
ConfigureSimulationsInParallel only caught OperationCanceledException, so an
unexpected throw escaping a worker (e.g. from a PublishEvent) faulted the task
and discarded every result - including the simulations that had already been
configured. Broaden the catch so the method always returns its partial results;
the presenter then applies the successful ones and marks the rest Faulted (or
Canceled when the user cancelled), matching the per-simulation isolation already
used inside the worker.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Show "Failed" instead of "Faulted" in the simulation update status
Map RunStatusId.Faulted to a "Failed" caption in the status grid rather than
falling back to the RunStatus display name.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
publicstaticreadonlystringCancelSimulationUpdateClarification="Cancel stops only simulations that have not started updating. Updates already in progress will finish.";
0 commit comments