fix: sql lab refetch button

[graceguo-supercat]

SUMMARY

See #15109, SQL Lab show "Refetch Results" button while fetching large query results. The fix in #15109 works, but it introduce another issue so we had to revert it. This PR adds extra fix on top of it.

See the 2nd commit: in airbnb most users still using client side localStorage to store query history. it seems sometimes the queries data was broken or messed up (for example, after user clear localStorage or delete some queries from History Tab). When user tries to re-run a query and sql lab start polling, sql lab can not find query id in the Redux state, which will cause exception, and show offline status.

ADDITIONAL INFORMATION

• Has associated issue: fix: SQL Lab show "Refetch Results" button while fetching new query results #15109
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

[codecov]

Codecov Report

Merging #16469 (147d103) into master (18be181) will decrease coverage by 0.00%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master   #16469      +/-   ##
==========================================
- Coverage   76.63%   76.62%   -0.01%     
==========================================
  Files        1002     1002              
  Lines       53637    53653      +16     
  Branches     6853     6861       +8     
==========================================
+ Hits        41104    41114      +10     
- Misses      12294    12300       +6     
  Partials      239      239              

Flag	Coverage Δ
javascript	70.81% <0.00%> (-0.01%)	⬇️

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

Impacted Files	Coverage Δ
superset-frontend/src/SqlLab/reducers/sqlLab.js	33.99% <0.00%> (-0.83%)	⬇️
superset-frontend/src/filters/utils.ts	85.18% <0.00%> (-8.15%)	⬇️
...nd/src/explore/components/DataTablesPane/index.tsx	75.24% <0.00%> (-1.99%)	⬇️
...ontrols/DndColumnSelectControl/DndMetricSelect.tsx	40.88% <0.00%> (-0.53%)	⬇️
...c/filters/components/Select/SelectFilterPlugin.tsx	80.89% <0.00%> (-0.22%)	⬇️
superset-frontend/src/views/CRUD/types.ts	100.00% <0.00%> (ø)
superset-frontend/src/components/Select/Select.tsx	76.57% <0.00%> (ø)
...perset-frontend/src/explore/components/Control.tsx	76.47% <0.00%> (ø)
...d/src/explore/components/DatasourcePanel/index.tsx	73.95% <0.00%> (ø)
...controls/DndColumnSelectControl/DndSelectLabel.tsx	77.27% <0.00%> (ø)
... and 2 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 18be181...147d103. Read the comment docs.

[ktmud]

LGTM given #15109 was already approved

[ktmud]

Reading the original description of #15109, I'm also wondering whether we can just replace the first "success" state to "fetching"?

[graceguo-supercat]

Reading the original description of #15109, I'm also wondering whether we can just replace the first "success" state to "fetching"?

I think what is this PR doing.
client-side can set fetching state, but engine-side, the query state in query table, is success. In the next polling, API will return status: success and try to overwrite redux state.

[ktmud]

I mean where is the original first success state set? Does it have to be success for it to not break something else?

[graceguo-supercat]

I mean where is the original first success state set? Does it have to be success for it to not break something else?

the first success is read from polling API, which is stored in queries table.

[ktmud]

Got it. Thanks for the clarification!