Creating new courses only works sometimes (flaky)

[CommanderStorm]

Describe the bug

Currently, creating new courses is pretty flaky.
It works, if you retry it 1-5 times (just trying the same things), but this should not be the standard.

This is pretty hard to debug from my side, since retrying it fixes the issue (it feels like something is fetching on demand but is not awaited??).
Is there something in your logs?

To Reproduce
Steps to reproduce the behavior:

1. Go to a course which has not been created (freshly created a few hours ago if that is a clue)
2. Click on the search result
3. See it not be created
4. goto 2, succeed after a few tries

Expected behavior
Courses should be able to be created

Screenshots

Desktop (please complete the following information):

• OS: Linux
• Browser: Chrome
• Version: 130.0.6723.91

Additional context
In general, this part of the UI is pretty hard to use.
No errors are printed to the console..

[karjo24]

Thanks for the issue. I can't reproduce this right now, which is why I can't really debug this either. However, I had a look into the code and may be able to add something of worth to the discussion.

it feels like something is fetching on demand but is not awaited

Seems unlikely to me. As far as I can see the following should happen: The search results are fetched from the API and then displayed as search results. If you click on any of them, the variables that store the information of the text boxes below "Manually enter Infos:" are set to the value of the respective members of the search result.
If e.g. the name of the search result and therefore the name below "Manually enter Infos:" were empty or undefined because they are not awaited, you probably wouldn't see anything in the list of search results in the first place.

However, the @click that handles the click event on any search result specifies that 1) the variables are assigned accordingly and then 2) the search query you typed should reset to "", which is not the case in your demo video. This makes me believe that the variable assignments before resetting searchQuery fail in some odd case and cause the other statements to not be executed, which (see above) I can't explain just by looking at the code.