Add UX hint that repos are being added

[ryanslade]

After adding repos as a user you are redirected to your repositories list page, something like https://sourcegraph.com/users/USERNAME/settings/repositories

However, since repos are being added in the background it's possible for the newly added repos not to appear in the list yet or even for the list to be empty.

It's not obvious at this point that anything is happening and that the only way to check for repos is to refresh the page.

I'm not sure what the best approach is here from a UX perspective, @quinnkeast WDYT?

[quinnkeast]

The original design for this flow has all of the repos shown, with a pending/cloning state for the repos that are queued for cloning. This is the end state we should be aiming to achieve. The long wait after hitting "Save changes" is a workaround solution to prevent this UX issue, and it's supposed to be completely blocking—the user shouldn't be redirected until all repos can be shown in the list (whether or not they've been cloned). In a sense, the problem here is that users are being redirected to the list when they shouldn't be.

@artemruts mentioned that it might be a matter of exposing this in-between state – we know it's meant to be added, but they don't exist yet.

[ryanslade]

@artemruts Any idea how we can avoid this?

[artemruts]

@ryanslade we have to stop waiting for the external services to update last synced timestamp and immediately navigate back to the repo list on successful response. The repo list then will make a UserRepositories request to fetch user repos and the response will have the mirrorInfo object where we can see individual sync states.

In practice UserRepositories request doesn't show the newly added repos for 3-7 seconds - that's why we wait so long at the save button.

We do have a way to show different statuses per repo if we receive them from the backend: https://sourcegraph.com/github.com/sourcegraph/sourcegraph/-/blob/client/web/src/user/settings/repositories/RepositoryNode.tsx (look for mirrorInfo)

@arussellsaw since you implemented the logic originally, does that sound right to you?

[artemruts]

@ryanslade I will try making on save navigation immediate now. We have only two APIs to try UserRepositories and externalServices to see if repos were added (in any state).

The problem I experienced - both queries will register changes at the same time (after 3-7 sec), as if the UserRepositories query is tied to the ExternalServices sync time. If the ExternalServices sync time takes 5 seconds, then the UserRepositories won't show new repos for 5 seconds.

[ryanslade]

In theory once last_synced_at has been updated the repos should exist in the repo and external_service_repos table.

When you say the UserRepositories requests doesn't show any repos do you mean 5-7 seconds after the sync has completed?

Ignore this, superseded by our chat in Slack.

[quinnkeast]

@ryanslade I will try making on save navigation immediate now. We have only two APIs to try UserRepositories and externalServices to see if repos were added (in any state).

The problem I experienced - both queries will register changes at the same time (after 3-7 sec), as if the UserRepositories query is tied to the ExternalServices sync time. If the ExternalServices sync time takes 5 seconds, then the UserRepositories won't show new repos for 5 seconds.

@artemruts Naïve question: would it work to capture the selected repos in a temporary client-side variable when hitting "Save changes" and then using that data to show the list of repositories, and then subsequently replace that list's data based on the API responses? It'd kind of be faking it for the sake of the perceived experience.

[artemruts]

@quinnkeast we could try that but I'm wondering if the following will happen:

1. user makes changes (we remember them)
2. user clicks save
3. user is navigated to the repo list (we populate it from the user's selection)
4. user clicks on a repo in list, and if this happens within 3-7 seconds we need to sync external services, user will see Repository not found search warning

Seems like in that case we're still tied to that 3-7 seconds 🤔

[quinnkeast]

Hmm, that makes sense. Goes back again to the idea that there's no "pending" state for repos—if there were, then it'd be totally okay to show a "Currently cloning" state for the repo when it's clicked in the list.

[ryanslade]

I don't think we should show the list of repos before they've been created in the repo table. Instead I think we can detect that we've started a background process and just indicate to the user that something is happening, then prompt them to refresh once we know we have new data. We'll need a new API for this, but it should be fairly straightforward as we can tap into the external_service_sync_jobs table. Clicking save currently adds a row to that table already.

We can then show a notice that “repos are being updated” or something and once we know we’re done we can show them the message to say new repos are available, please refresh. I don’t think we should refresh automatically in case they are browsing through their repos and have paginated beyond the first set of results. Once new results arrive the entire list of repos would be reordered anyway since we order by name.

[artemruts]

Ryan, do you want me to make an ticket for this new endpoint?

[ryanslade]

Ryan, do you want me to make an ticket for this new endpoint?

Yes please

[quinnkeast]

@artemruts do you have this ticket ready?

[artemruts]

@artemruts do you have this ticket ready?

https://github.com/sourcegraph/sourcegraph/issues/20318