You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As part of the per-stream process we discovered some shortcoming last week and will require a slightly different slow than we currently have. The full flow for the FE what happens is documented in this flowchart.
The main adjustments to make in the FE are:
When the user hits the "save" button when updating a connection, we need to check, if the configured catalog we're about to send to the web_backend/connection/update API differs anyhow (deep compare) from the initial catalog we loaded. If we "refreshed the source catalog" in the meantime, we still need to compare against the original one that was loaded when the page was loaded (not the one we got back from the web_backend/connection/read (withRefreshedCatalog: true) call.
If they are still the same, we simply call web_backend/connection/update as we do today. We're not needing to send withRefreshedCatalog to that API, since we're getting rid of it.
If the catalogs differ anyhow, we'll make a call to web_backend/state/get_type first to determine the state type of the connection. After that we show a modal warning the user, that we'll reset their streams. The wording depends on the state type we received from the prior API call. For "legacy" a full reset will happen, so we mention this, for "global" and "stream" only changed streams will be resetted, we'll mention that in the warning modal (exact wording still to be done on the PR). The modal does not offer an option not to reset (as our current one does). It just will allow confirming or cancelling (in which case the connection won't be saved). If the user confirms, we'll call web_backend/connection/update (also without withRefreshedCatalog) with the new changes.
We'll be getting rid of the current modal that asks whether or not the connection should be reset or not.
All APIs are already available. We can create that PR, but must wait with merging for the corresponding API changes to be ready, so that the behavior will match our expectations.
The text was updated successfully, but these errors were encountered:
As part of the per-stream process we discovered some shortcoming last week and will require a slightly different slow than we currently have. The full flow for the FE what happens is documented in this flowchart.
The main adjustments to make in the FE are:
When the user hits the "save" button when updating a connection, we need to check, if the configured catalog we're about to send to the
web_backend/connection/update
API differs anyhow (deep compare) from the initial catalog we loaded. If we "refreshed the source catalog" in the meantime, we still need to compare against the original one that was loaded when the page was loaded (not the one we got back from theweb_backend/connection/read
(withRefreshedCatalog: true
) call.If they are still the same, we simply call
web_backend/connection/update
as we do today. We're not needing to sendwithRefreshedCatalog
to that API, since we're getting rid of it.If the catalogs differ anyhow, we'll make a call to
web_backend/state/get_type
first to determine the state type of the connection. After that we show a modal warning the user, that we'll reset their streams. The wording depends on the state type we received from the prior API call. For "legacy" a full reset will happen, so we mention this, for "global" and "stream" only changed streams will be resetted, we'll mention that in the warning modal (exact wording still to be done on the PR). The modal does not offer an option not to reset (as our current one does). It just will allow confirming or cancelling (in which case the connection won't be saved). If the user confirms, we'll callweb_backend/connection/update
(also withoutwithRefreshedCatalog
) with the new changes.We'll be getting rid of the current modal that asks whether or not the connection should be reset or not.
All APIs are already available. We can create that PR, but must wait with merging for the corresponding API changes to be ready, so that the behavior will match our expectations.
The text was updated successfully, but these errors were encountered: