fix: couple of issues in launch fluent

[mayankansys]

Context:

launch_fluent() had sequencing issues in startup flow:

• case/case-data handling was not guaranteed to run before journal processing, and
• In lightweight mode, sync could begin before journal execution completed.
• This could lead to inconsistent initialization behavior depending on launch inputs.

Change summary:

This PR refactors the launch flow in launch_fluent() to enforce deterministic order:

• Case / case-data files are processed first
• Journal files are processed after case inputs
• In lightweight mode, sync is deferred until journal execution fully completes

Impact:

• Improves correctness and reliability of Fluent startup flow
• Reduces risk of order-related runtime issues in lightweight launches
• Strengthens confidence with automated test coverage for these launch pathways
• Affects behavior where users provide case files, case-data files, journals, and/or use lightweight mode

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[mkundu1]

@mayankansys Is the following happening in the lightweight-mode?

bg session: read case + settings -> read journals -> make this as the main session -> apply changes that user made in the fg session
fg session: read settings -> start accepting changes from user -> shutdown after the main session is transferred

The journals should be read in the background session which reads the full mesh before it.

Additionally, I think the journals should be read in the foreground session also, because use will expect the journal is already read when they start making change in the activated foreground session. But I'm not sure if the journal has, e.g., a solve call, whether that will be a no-op when only settings are read.

[mayankansys]

@mayankansys Is the following happening in the lightweight-mode?

bg session: read case + settings -> read journals -> make this as the main session -> apply changes that user made in the fg session fg session: read settings -> start accepting changes from user -> shutdown after the main session is transferred

The journals should be read in the background session which reads the full mesh before it.

Additionally, I think the journals should be read in the foreground session also, because use will expect the journal is already read when they start making change in the activated foreground session. But I'm not sure if the journal has, e.g., a solve call, whether that will be a no-op when only settings are read.

Thanks @mkundu1 for the question and to make sure I understand before I rework on this:

The PR fixes the ordering but you're pointing at a separate problem which was, In lightweight mode the journals currently run on the foreground settings whihc doesn't have mesh.
I agree that's wrong for the mesh-dependent journals. A journal that calls the solve needs the mesh, so should I run on the background session that reads the full mesh matching the order which you described.

If the journal has solver call then I expect a solve in settings only session to either error or no-op which is more evidence the journals belong on the bg session. Kindly let me know what's you take on it.

One issue while implementation can be the bg session is inside read_case_lightweight() but journal reading currently happens in the launchers process_case_data_and_journals which has no handle to the bg session.
For doing this properly I think we need to move the journal reading into the lightweight read path.

Before I move forwards kindly let me know:

• Am I understading the thing properly and am I on the correct path ?
• Should Journals run only on the bg session or is there a case where they also need to run in the fg session ?