Render correct error and enable buttons when pull failed

[nightnei]

Related issues

• Fixes STU-1506

How AI was used in this PR

AI assisted me with the investigation and writing code, but the solution is mine.

Proposed Changes

This PR fixes two issues when pulling failed:

1. Before, the buttons were always disabled. This PR fixes it to enable "Disconnect/Pull" buttons after failing.
2. Before, we always printed error "Failed to check backup file size. Please try again." for any reason of failing the the pulling flow. We should at least print a real general error, e.g., "Pulling failed" or better - specific error, to help the user understand the issue at a glance and fix it w/o extra actions.

Testing Instructions

1. Create a Pressable site (I used Pressable, but teh same should work with dotcom)
2. Create a new DB table "wp_Links", so that you have both wp_links and wp_Links
3. Open Studion -> Sync -> Pull this site to Studio
4. Immediately cancel pulling
5. Assert that it's canceled (However it's not expected to have regression here, but let it be 😄)
6. Pull again
7. Wait for "Downloading backup" status and cancel
8. Assert that it's canceled well, w/o regression (it's important, since it's where we are testign new currentState?.status.key === 'cancelled' condition)
9. Pull again
10. Wait till you see an error
11. Assert that you see real error (Previously you would see Failed to check backup file size.)
    :
12. Click "Ok"
13. Assert that "Disconnect" and "Pull" buttons are enabled (Previously they were still disabled)

[wpmobilebot]

📊 Performance Test Results

Comparing 2555182 vs trunk

app-size

Metric	trunk	2555182	Diff	Change
App Size (Mac)	1261.00 MB	1261.00 MB	+0.00 MB	⚪ 0.0%

site-editor

Metric	trunk	2555182	Diff	Change
load	1593 ms	1894 ms	+301 ms	🔴 18.9%

site-startup

Metric	trunk	2555182	Diff	Change
siteCreation	8171 ms	9148 ms	+977 ms	🔴 12.0%
siteStartup	4174 ms	4292 ms	+118 ms	🔴 2.8%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[katinthehatsite]

Do you we could use getErrorFromResponse here to make sure we are not exposing raw and unclear strings to users?

[nightnei]

Thanks Kat, I took a look at that function, and I see it checks for error inside error. Looks like it's some workaround to fix backend responses. So, getErrorFromResponse should be used directly to parse responses immediately. But in the upper level, like in this PR - it should not be used.
Moreover, getErrorFromResponse returns either error.error or generic string Studio was unable to connect to WordPress.com. Please try again.. It doesn't return simple error. It means that in the case described in this PR, getErrorFromResponse would return Studio was unable to connect to WordPress.com. Please try again., instead of the original no such file or directory, lstat '/var/folders/17/pw87dj654w53d10tbm0_tnhw0000gn/T/studio_backupBVYe8E/sql/wp_Links.sql'.
So we should go with the current state of changes in this PR.

[katinthehatsite]

Alright, let's leave as is then 👍 Thanks for the explanation!

[katinthehatsite]

The changes look good, thanks for this improvement 👍

[katinthehatsite]

There was a conflict with trunk on this PR so I resolved it and we can merge when the checks pass.

[fredrikekelund]

Why do we also need to check the pull state status here? In which scenario might the signal be aborted, but the pull state would have a different status?

[nightnei]

In which scenario might the signal be aborted, but the pull state would have a different status?

TBH, I don't remember exactly 😅 I looked at my testing steps to recall, and it's the "Downloading backup" step, but, AFAIR, when I was debugging - it was caught here as "importing".

[nightnei]

Why do we also need to check the pull state status here?

To avoid muting errors and print them to users. Before, we just said "Import failed," which didn't help users to investigate the actual issue and try to fix it themselves.

Additionally, this PR fixed a misleading error in other cases - we always printed an irrelevant error "Failed to check backup file size. Please try again."