Keep previous query result if current query result in error

[abbyhu2000]

Description

Currently, an error query will display no result.
This PR change to keep previous query result if current query result in error.

Issues Resolved

Screenshot

If the query result in error, it will keep the previous query result without updating the canvas
https://github.com/user-attachments/assets/f72b8a74-ad71-4261-8493-fc5e3b24a74b

If the first query result in error, it will show the refresh data screen.

Screen.Recording.2024-11-13.at.5.24.18.PM.mov

Testing the changes

Changelog

• fix: Keep previous query result if current query result in error

Check List

• All tests pass
  • yarn test:jest
  • yarn test:jest_integration
• New functionality includes testing.
• New functionality has been documented.
• Update CHANGELOG.md
• Commits are signed per the DCO using --signoff

[joshuali925]

if the first query returned an error and there are no previous query or previous rows, what does it show?

[abbyhu2000]

Should we show no result UI here if the first query we execute is invalid? @ashwin-pc

[ashwin-pc]

Yes it should show the last valid UI state

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 56.39%. Comparing base (c20c041) to head (e70cf4e).
Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8863      +/-   ##
==========================================
- Coverage   60.92%   56.39%   -4.54%     
==========================================
  Files        3800     1239    -2561     
  Lines       90841    25913   -64928     
  Branches    14313     4437    -9876     
==========================================
- Hits        55343    14613   -40730     
+ Misses      31978    10559   -21419     
+ Partials     3520      741    -2779     

Flag	Coverage Δ
Linux_1	?
Linux_2	56.39% <ø> (ø)
Linux_3	?
Linux_4	?
Windows_1	?
Windows_2	?
Windows_3	?
Windows_4	?

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

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

[kavilla]

nit: imo this is getting really hard to understand when and where and i can imagine a regression if someone slightly changes the logic here.

i think we should consider a restructuring of this code.

to me this would be the psuedo code lemme know if im wrong

if rows.length exists, show results based on status
   switch fetchState.status
      READY, LOADING, ERROR
         isEnhancements return either component A or component B
      default
        nothing
else if no rows, handle different status states
   switch fetchState.status
      case: NO_RESULTS
        return no results component
      case: UNITIALIZED, ERROR
        return uniitilizaed component
      case: LOADING
        return loading spinner
      default:
        nothing

[abbyhu2000]

i think the above psudo logics are not the same as the current logics

Rows exist or not exist only make a difference for loading status and error status;
ready status and un-initialized and no result status do not care about rows exist or not

[abbyhu2000]

• todo: add a cypress test/unit test for these behaviors