Can't fork a project to a deleted name

[prisamuel]

time="2019-08-05T11:47:44Z" level=info msg="[fork] creating fork in zfs..." forkId=2841566f-e1ad-496e-bb6f-fd13607eb424 forkName=project-82c18d83-default-workspace forkNamespace=lukemarsden originFilesystemId=044bbd5f-f567-4c95-8c2d-30957ef2ba5b originSnapshotId=fdc298d9-2d43-4484-b767-65eb87e41a11
time="2019-08-05T11:47:44Z" level=info msg="ZFS fork completed" duration=304.114607ms
time="2019-08-05T11:47:44Z" level=error msg="Error registering fork" error="The name lukemarsden/project-82c18d83-default-workspace is already in use"
time="2019-08-05T11:47:44Z" level=info msg="<transition> 044bbd5f-f567-4c95-8c2d-30957ef2ba5b to active waiting (from active waiting, 38.47s ago)"
time="2019-08-05T11:47:44Z" level=error msg="unexpected response 'cannot-fork:error-registering-fork' (expected: 'forked') - &types.EventArgs{\"err\":map[string]interface {}{}}"
time="2019-08-05T11:47:44Z" level=info msg="entering active state for 044bbd5f-f567-4c95-8c2d-30957ef2ba5b"

On the front-end this appears to the users as follows

[binocarlos]

It seems that we are taking the id of the upstream project and attempting to use it as the dotname for the forked project

kshitizmandal/collaborate-test (upstream)
project id: 017ca5b4-1981-47ee-b849-6e781d2eed07
dotname: kshitizmandal/project-017ca5b4-default-workspace

utsavratnatuladhar/collaborate-test-old (fork)
project id: 78833d36-c950-4c44-8637-d723e295c46b
dotname: utsavratnatuladhar/project-017ca5b4-default-workspace

017ca5b4 is being used in the project name in both cases - this should probably be using the id of the new project so:

utsavratnatuladhar/project-017ca5b4-default-workspace

should be:

utsavratnatuladhar/project-78833d36-default-workspace

The issue fusemachines are reporting is because there is already a fork of kshitizmandal/collaborate-test and the new project is trying to use the same dotname and so clashes.

The other issue is the frontend is not reporting you already have a fork and as such the fork button should not even be visible.

[binocarlos]

This would explain however why when deleting a project it doesn't clear up this issue because it's always using the upstream project id as the dotname

[binocarlos]

OK - when deleting a project - the dot is not deleted meaning whenever you try to re-fork a project - it will attempt to use the same dotname and because the dot is already there - it will fail

[binocarlos]

The forks property of https://cloud.dotscience.net/project/017ca5b4-1981-47ee-b849-6e781d2eed07/runs/list is empty - even though we have a fork of it - this means the UI is showing a fork this project button rather than a you have a fork of this project leading to the same error above

[binocarlos]

Ok - so I think this is more to do with the fact the forks table in production is empty - having just created a fork of the public project - there was an entry in the forks table for it - having then deleted the forked project - it removed the associated dot and everything was fine.

Lukes project (in the original issue) and utsavs project both don't have an entry in the forks table which would explain a) why lukes deleted project fork dot remains preventing another from being created b) why the fork this project button is visible for utsav

[binocarlos]

The issue here is that deleting any project that is a fork seemingly wipes the forks table for all forks. This leaves dot's dangling such that the next time a fork is being created - it will fail because the dotname is aready taken. It also explains why the frontend lets users attempt to fork a project they already have a fork of (because there is no longer a record of that fork).

• there are 3 users - admin, bob & binocarlos
• there is 1 project - admin/housing-prices
• bob & binocarlos both fork housing-prices
• select * from forks gives 2 rows (as expected)
• bob deletes the project for his fork
• select * from forks gives 0 rows - bob deleting his project has deleted binocarlos's fork