fix: remove loader regression in no-code-model set-model handler

[abhizipstack]

Summary

• Remove .finally(() => setIsLoading(false)) from handleSourceDestinationChange in no-code-model
• The finally block was resetting the loader after both success and error paths, which interfered with the loading state needed by runTransformation() on the success path
• The catch block already handles resetting the loader on errors

Root cause

Introduced in be398f6 — the .finally() block was added alongside error notification improvements but caused a regression where the loader would disappear prematurely on successful model configuration.

Test plan

• Open a no-code model, configure source/destination, click Apply
• Verify the loader stays visible until the transformation completes
• Verify on error the loader is properly dismissed

🤖 Generated with Claude Code

[tahierhussain]

LGTM

[greptile-apps]

Greptile Summary

This PR removes the .finally(() => setIsLoading(false)) block from handleSourceDestinationChange in no-code-model.jsx. The fix correctly addresses a regression where the loading indicator was being dismissed prematurely on the success path, before runTransformation() (and the subsequent getSampleData()) had completed their async work.

Key changes:

• Removes 3 lines from handleSourceDestinationChange that were prematurely resetting the loading state after a successful set-model API call
• The .catch() block retains its own setIsLoading(false) call, so the error path continues to work correctly

Why the fix is correct:

• On success: runTransformation(spec) is called inside .then(), which itself calls setIsLoading(true) and then delegates teardown to getSampleData() — which uses a .finally(() => setIsLoading(false)) to clear the loader. The removed .finally() was firing synchronously after the .then() callback returned but before runTransformation's async HTTP call completed, causing the loader to vanish too early.
• On error: setIsLoading(false) in the .catch() block already handles cleanup.

Confidence Score: 5/5

This PR is safe to merge — the fix is minimal, targeted, and correctly addresses the described regression.

Single 3-line removal with a well-understood root cause. The loader lifecycle is now correctly handled end-to-end: runTransformation → getSampleData → .finally(() => setIsLoading(false)). The error path was already correct and remains untouched. No new logic is introduced, no other call sites are affected, and no P1/P0 issues were found.

No files require special attention.

Vulnerabilities

No security concerns identified.

Important Files Changed

Filename	Overview
frontend/src/ide/editor/no-code-model/no-code-model.jsx	Removes 3 lines (the .finally(() => setIsLoading(false)) block) from handleSourceDestinationChange; fix is targeted and correct — the loader lifecycle now properly propagates through runTransformation → getSampleData.

Sequence Diagram

sequenceDiagram
    participant U as User
    participant H as handleSourceDestinationChange
    participant RT as runTransformation
    participant GS as getSampleData

    U->>H: Click Apply
    H->>H: setIsLoading(true)
    H->>H: POST /set-model

    alt Success
        H->>RT: runTransformation(model_data)
        RT->>RT: setIsLoading(true)
        RT->>RT: POST /execute/run
        RT->>GS: getSampleData(spec)
        GS->>GS: setIsLoading(true)
        GS->>GS: GET /content
        GS->>GS: setIsLoading(false) [.finally()]
        Note over H,GS: Loader stays until getSampleData completes
    else Error
        H->>H: notify error
        H->>H: setIsLoading(false) [.catch()]
        Note over H: Loader dismissed on error
    end

Loading

_{Reviews (1): Last reviewed commit: "fix: remove loader reset from finally bl..." | Re-trigger Greptile}