feat(blueprints): add logs to creation flow

[rmnbrd]

feat(blueprints): add logs to creation flow

This PR introduces a non-dismissible modal, that opens at the end of the blueprint-based service creation flow. This modal surfaces the logs of everything happening during the creation of the service.

Screenshots / Recordings

https://www.loom.com/share/7ad14a4d0fe248b1bf1b34631a171d48

Testing

• Changes tested locally in the relevant Console's pages and Storybooks
• yarn test or yarn test -u (if you need to regenerate snapshots)
• yarn format
• yarn lint

PR Checklist

• I followed naming, styling, and TypeScript rules (see .cursor/rules)
• I performed a self-review (diff inspected, dead code removed)
• I titled the PR using Conventional Commits with a scope when possible (e.g. feat(service): add new Terraform service) - required for semantic-release
• I only kept necessary comments, written in English (watch for useless AI comments)
• I involved a designer to validate UI changes if I am not a designer
• I covered new business logic with tests (unit)
• I confirmed CI is green (Codecov red can be accepted)
• I reviewed and executed locally any AI-assisted code

[codecov]

Codecov Report

❌ Patch coverage is 62.24490% with 37 lines in your changes missing coverage. Please review.
✅ Project coverage is 43.81%. Comparing base (d554e0d) to head (c33ba38).
⚠️ Report is 2 commits behind head on staging.

Files with missing lines	Patch %	Lines
.../blueprint-step-summary/blueprint-step-summary.tsx	58.06%	23 Missing and 3 partials ⚠️
...loading-modal/blueprint-creation-loading-modal.tsx	59.09%	5 Missing and 4 partials ⚠️
...print-creation-logs/use-blueprint-creation-logs.ts	85.71%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           staging    #2816      +/-   ##
===========================================
- Coverage    46.93%   43.81%   -3.12%     
===========================================
  Files         1263      475     -788     
  Lines        27061    12499   -14562     
  Branches      7887     3852    -4035     
===========================================
- Hits         12701     5477    -7224     
+ Misses       12194     6051    -6143     
+ Partials      2166      971    -1195     

Flag	Coverage Δ
unittests	43.81% <62.24%> (-3.12%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Copilot]

Pull request overview

This PR enhances the blueprint-based service creation flow by introducing a non-dismissible “creation in progress” modal that streams and displays real-time creation logs, with recovery actions when an error is detected.

Changes:

• Add a blocking modal at the end of the blueprint creation flow to display live creation logs and error recovery actions (retry / edit config).
• Introduce a WebSocket-based hook to subscribe to deployment logs and filter only logs emitted by the created blueprint.
• Update and add unit tests covering the modal, the new logs hook, and the blueprint creation flow integration.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
libs/domains/services/feature/src/lib/service-creation-flow/blueprint/blueprint-step-summary/blueprint-step-summary.tsx	Wires the new logs subscription and opens the non-dismissible modal during/after blueprint creation, including retry/edit flows.
libs/domains/services/feature/src/lib/service-creation-flow/blueprint/blueprint-step-summary/blueprint-creation-loading-modal/blueprint-creation-loading-modal.tsx	New modal UI that displays streaming logs, auto-scrolls, and exposes recovery actions on error.
libs/domains/services/feature/src/lib/service-creation-flow/blueprint/blueprint-step-summary/blueprint-creation-loading-modal/blueprint-creation-loading-modal.spec.tsx	Adds unit tests validating skeleton rendering, error highlighting, and recovery actions.
libs/domains/services/feature/src/lib/service-creation-flow/blueprint/blueprint-creation-flow.spec.tsx	Updates flow tests to mock environment + logs hook and assert logs subscription is enabled with the created blueprint id.
libs/domains/services/feature/src/lib/hooks/use-blueprint-creation-logs/use-blueprint-creation-logs.ts	New hook subscribing to /deployment/logs and filtering to blueprint-emitted logs for the created blueprint id.
libs/domains/services/feature/src/lib/hooks/use-blueprint-creation-logs/use-blueprint-creation-logs.spec.tsx	Adds unit tests for subscription enablement conditions and blueprint-only log filtering.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[RemiBonnet]

The code LGTM 👍

I think the experience is a bit off: the logs appear too briefly, and we go back to the service list immediately when there’s no error, so we can’t really read them. Could we show this modal only when there's an error? wdyt @TheoGrandin74?

[TheoGrandin74]

@rmnbrd I was a bit surprised by the skeleton while testing, I'm wondering if we should just have the spinner on the button while the logs are loading, and then display the log directly, without the skeleton. This way I think it could be sequenced and understood as:

• Sending the signal to begin the creation (spinner)
• Actually creating the service (the logs)

Also thinking that if a blueprint is faster to create than the logs are to be loaded, it will be cleaner. Wdyt?

[rmnbrd]

I'm wondering if we should just have the spinner on the button while the logs are loading, and then display the log directly, without the skeleton

@TheoGrandin74 Yes indeed! Good call, let's do that! That will be cleaner this way.
But that does not mitigate the issue of the modal appearing and disappearing within a matter of a few seconds. The user won't really have time to read the logs. I'm not sure what should we do about this?