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
Currently, it is possible to export / check for an exercise without any UUID. While this works technically, the resulting check (and message) are not working as intended.
Consider the following example:
I have a new task on CodeOcean
That task has never been exported before, so that the UUID attribute is null
Now, I click on export, which will check the UUID through our /import_uuid_check route. Resulting is a query:
SELECT"exercises".*FROM"exercises"WHERE"exercises"."uuid" IS NULLLIMIT1
As you can image, this will find any other task that has not been exported before (UUID is null). Hence, the resulting message is misleading:
A corresponding task has been found on CodeHarbor. You can export the exercise to transfer all changes made on CodeOcean to CodeHarbor. Careful: This will overwrite all potential changes made on CodeHarbor.
We should correct this behavior. Potentially, there are two solutions:
Do not check for a specific exercise if the current one has no UUID (because we cannot overwrite it anyway). However, the check currently also provides information on the access token's validity, which we might still want to validate.
Catch that special case on the other side, and always return that no existing exercise was found.
These two checks should be checked / implemented in CodeOcean and CodeHarbor. I just experienced it in an CodeOcean-only scenario (with two CodeOcean instances connected to each other), but can imagine that it might be valid for CodeHarbor as well.
The text was updated successfully, but these errors were encountered:
Currently, it is possible to export / check for an exercise without any UUID. While this works technically, the resulting check (and message) are not working as intended.
Consider the following example:
null
/import_uuid_check
route. Resulting is a query:We should correct this behavior. Potentially, there are two solutions:
These two checks should be checked / implemented in CodeOcean and CodeHarbor. I just experienced it in an CodeOcean-only scenario (with two CodeOcean instances connected to each other), but can imagine that it might be valid for CodeHarbor as well.
The text was updated successfully, but these errors were encountered: