After editing a connection's replication settings and confirming a reset, the page doesn't refresh

[andyjih]

Repro Steps:

1. Edit streams in a connection
2. Press "Save Changes"
3. Press "Save Connection" in the modal confirming the reset
4. See that the streams added/removed are still shown as pending.

Expected behavior:

• I would expect the contents of the page to refresh/reload and show the newly saved configuration settings.

[octavia-squidington-iii]

cc @airbytehq/frontend

[edmundito]

@andyjih do you still have the gif showing what's going on? It looks like it did not upload to the issue.

[andyjih]

[timroes]

@dizel852 Ideally you should check the behavior with #15332 merged. I don't believe if will fix it (not tested though yet), but it changes a bit how data is passed into this form, which might have an affect on the specific fix you want to do, to reset the form.

[dizel852]

@dizel852 Ideally you should check the behavior with #15332 merged. I don't believe if will fix it (not tested though yet), but it changes a bit how data is passed into this form, which might have an affect on the specific fix you want to do, to reset the form.

Hm, yeah, you're right, that makes sense.
Ok, will wait for merge

[dizel852]

Just checked on master - it seems like it works as should.

If we carefully look at @andyjih 's gif, we will notice that the "Save changes" action is not fully completed - we didn't get a response from the backend, and the "Save changes" button is in a loading state(grey out and spinner). Applying changes process takes some time. And only after this process is completed, our replication settings table is refreshed.

Here is the loom:
https://www.loom.com/share/f5cf94da95904f0d9a880b415e9577e5

I think it's a UX problem - as we notice, the user didn't understand that his request is processing.
Probably we need to add some loading state for streams catalog, example:

@andyjih @timroes WDYT?

[andyjih]

Do you happen to know what the backend is doing before sending a response?

[dizel852]

Do you happen to know what the backend is doing before sending a response?

No, to be honest 🤷🏻‍♂️

[andyjih]

What's interesting is if I refresh the page, the newly saved configuration is there, so it suggests to me that the configuration is saved even if the backend has given a response yet. Is that correct?

[dizel852]

What's interesting is if I refresh the page, the newly saved configuration is there, so it suggests to me that the configuration is saved even if the backend has given a response yet. Is that correct?

Yes, that's right. I guess under the hood of "Save changes" we involve multiple steps, like:

1. Update selected streams list
2. Reset schema
3. Run sync job
4. Other possible steps...

So when all steps are passed finally, we get the response that the "save changes" operation is completely finished.
I'm pretty sure it was made intentionally since we guarantee that the "save changes" operation is consistent.

Recently we had the opposite case - after connection deletion, it was still observable(just for a few sec) in GET requests, and the "Setup connection" step at onboarding page crashes.

IMO We have not too many options on how to solve that:

1. Add an additional loading indicator for Streams Table
2. Ask Backend guys to find out why the "save changes" operation takes so long. Probably there are some extra steps, and we could get the response faster.

[andyjih]

I think showing an additional loading indicator seems correct to me. @timroes do you have opinions here?

For a future github issue, I think we'll want a way to communicate with users that the configuration was saved, but background jobs are still happening.

[timroes]

I also think the loading indicator must be the best solution. In general, when the backend APIs like this take a long time to complete it often is the case that as part of that API we need to spin up/wait for some Temporal tasks, which usually adds most of the overhead. But I agree that this APIs ideally should return as soon as we have a consistently saved state (whether or not all temporal tasks are already done, unless of course we only have that consistent state only after the temporal tasks are done).

@dizel852 could you maybe open a separate issue for the BE team for that specific API to look into if it would make sense to return the response earlier as long as we're consistent?

[dizel852]

Backend issue: #15657