Render profiles for deleted repos if they have activity

[jtourkos]

When a user deletes a repo from GitHub the app will show a "500 Internal Server Error" page when trying to navigate to that (claimed) project's page.

I think we should catch it, and show a proper message. Wdyt?

[efstajas]

I think for now it should just be a 404, probably.

It is somewhat awkward that people that have previously set up a stream / split to a now-deleted project will of course continue sending funds, but you can't see those supporters etc. anymore once the repo was deleted. Perhaps longer-term we should show a variation of the project profile just titled "Deleted repo" which still shows the supporters section and most stats, if a non-existing repo on GH is receiving funds on Drips for some reason.

[brandonhaslegs]

Need a design for this deleted GitHub repo page

[brandonhaslegs]

Does this also happen when a repo is renamed? If it only happens when a project is deleted, this would work. Some assumptions:

• Users can still support
• The funds might not be collected (this is purely conjecture but if they delete the project maybe they're also not collecting funds anymore?)

Or if it applies to renaming and deleting (I could imaging if the project is just not found by the same name it would be the same as it being deleted?), then the message should include that:

Can comment on Figma here if you want https://www.figma.com/file/vyI7f996JF8zwhnXwAwXdC/%F0%9F%92%A7-Drips?type=design&node-id=6392-70118&mode=design

[efstajas]

@brandonhaslegs When a project is renamed, it's a bit tricker.

Since we figured out that RepoDriver accounts are case-sensitive, we look up the "correct" name of any repo with the GitHub API before loading the project page, in order to correct wrong casing. That API also "redirects" old repo names to the new one if a repo has been renamed. Meaning that if you had a repo called /foo/1234 and renamed it to /foo/ABCD, the following would happen on drips:

• On the Projects tab, the project still appears as /foo/1234
• When you click it, you actually see the project for /foo/ABCD though — the unclaimed project associated with the new repo name.
• Already-existing splits to /foo/1234 continue going to the account associated with the old repo name, but you don't have any way to see or edit this old project
• When someone enters the URL for /foo/1234 OR for /foo/ABCD into a splits editor to split to your project, it always automatically gets corrected to the new URL, which is good

The question is how this should work. I think the most straightforward way would be to:

1. Disable the "auto-correct" of repo names when clicking on a project split or project card anywhere in the app. That would ensure that you always see the actual project someone is splitting to, even if they're splitting to one that has since been renamed. It also means that as the owner of a project with an underlying repo that has been renamed, you can still see and edit the splits of those old projects.
2. Prompt the owner of a project with a renamed repo to claim the new project with the new name as well. Basically, the owner must go through the claim process again for their project under the new name, except of course the FUNDING.json is already there.

In practice, this would result in users that own repos that have been renamed seeing both the old and the new project in their projects tab, which is good because they can then manage the splits for the old project still. We could improve this further in the future and e.g. let people hide the old project or something like that, or even auto-redirect all funds from the old project into the new. No new splits should ever come in to the old project after a rename, so you just need to keep it around in order to manage funds coming in from previously-created ones.

[efstajas]

@brandonhaslegs Re the design for a deleted project, I don't think we should make it possible to still support it. If the repo is deleted, that's a pretty clear signal that it shouldn't receive support anymore.

Imo, it should

• still allow editing splits, metadata etc. for the project owner
• be in complete "read-only" mode (as in, can't even support) for anyone else
• reject attempts to create a new split to the project (as in, when you enter the URL to the deleted repo into a splits editor, it should reject it with "Repo doesn't exist")

[CodeSandwich]

I just realized something: when you rename a repo, all API calls using the old name are re-routed to the new name. This means that if the smart contract asks the oracle to query GH using the old name, GH will actually handle it correctly by returning FUNDING.json using the new name. For RepoDriver it will mean that 2 independent account IDs (derived from the old name and from the new name) coincidentally have the same owner, which for it is perfectly fine.

[brandonhaslegs]

So I updated the text above the project to this

<projectName> was deleted from GitHub. You can’t support it on Drips anymore, but existing support will continue to drip to it. The owner can still collect all dripped funds.

And I removed the support card.