I can reproduce. There are a few things going on here.

First: why does it say the event is no longer connected?
In https://meta.wikimedia.org/wiki/Special:EventDetails/1979, the course shows as connected and up-to-date; so, indeed, the application never learned that it got disconnected. So I went on logstash and looked for API requests for event 1979 in the CampaignEvents channel. There are a few failed attempts to sync participants, which are expected given the bug. Filtering those out, we're left with 3 requests only: two successful confirm_event_sync (status code 200; presumably, the first one is dry_run and the second isn't) and a successful update_event_participants immediately to follow. These are all from July 28th 10:00, i.e., when the event was created. This further confirms that whatever caused the course to get unlinked, it did not happen on our side. Maybe something on the dashboard side?

@Ragesoss Hi! This course was associated to this event on-wiki on July 28th. However, it looks like it is no longer linked. This did not happen on our side AFAICT. Do you have an idea of how it might have happened, and if it could be prevented going forwards? Thanks!

Second: why is no error shown?
Because there is currently no way to get the error text in the user language. That is tracked in T269492, and I had filed T311423 3+ years ago for this exact use case. Things don't appear to have changed since then. However, we still had a failure mode in place: if the API request failed, we would redirect you to Special:RegisterForEvent, where no API request is involved, and therefore we can show the full error message. Not the best UX, but better than nothing and we hoped it'd be both rare and temporary. However, this is no longer working. I did a git bisect and unsurprisingly, I broke it in r1140774. I'll fix this to restore the previous failure mode.

Third: should this specific error prevent registration?
In principle, if a course is no longer linked with an event, we could still allow the user to register, and just skip the tracking tool updates. However, I would first like to understand why the unlinking happened. I believe that preventing it from happening in the first place would be a superior fix, as otherwise the application would still be left in an inconsistent state. Note, if we figure this out and choose to continue failing, we should notify the organizer of that event (they should be able to just use EditEventRegistration to remove the association).

Change #1179747 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] resources: Fix promise rejection handlers

https://gerrit.wikimedia.org/r/1179747

In T401873#11095223, @Daimona wrote:

@Ragesoss Hi! This course was associated to this event on-wiki on July 28th. However, it looks like it is no longer linked. This did not happen on our side AFAICT. Do you have an idea of how it might have happened, and if it could be prevented going forwards? Thanks!

This isn't supposed to be possible without either modifying the course record from the backend or unlinking via a request from CampaignEvents. I'm pretty confident no one changed it on the backend. I did a quick review of the related code, and I don't spot any obvious things that would allow this to happen, but I will do some manual testing and further poking around to see if there are any ways of blanking or resetting the data structure that holds the event_sync flag that I missed.

Change #1179747 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] resources: Fix promise rejection handlers

https://gerrit.wikimedia.org/r/1179747

In T401873#11117441, @Ragesoss wrote:

In T401873#11095223, @Daimona wrote:

@Ragesoss Hi! This course was associated to this event on-wiki on July 28th. However, it looks like it is no longer linked. This did not happen on our side AFAICT. Do you have an idea of how it might have happened, and if it could be prevented going forwards? Thanks!

This isn't supposed to be possible without either modifying the course record from the backend or unlinking via a request from CampaignEvents. I'm pretty confident no one changed it on the backend. I did a quick review of the related code, and I don't spot any obvious things that would allow this to happen, but I will do some manual testing and further poking around to see if there are any ways of blanking or resetting the data structure that holds the event_sync flag that I missed.

Interesting! I double-checked the logs for unsync_event requests in the last month. I see a few of them, but nothing for event 1979 before today (it seems that the event got associated with a different course today). So, I can confirm that we did not make a request to unlink the course.

I think I have a good guess at what happened, a race condition of sorts.

The course on the dashboard was create very soon before it was synced, and it actually started its first update very quickly, right before the sync. (This is unusual, as the update queue normally has nontrivial latency.)

My guess is that the event sync happened in the meantime, but got clobbered in the flags data structure by the update logging. I'll file an issue to make sure we fix that possibility.

In T401873#11142011, @Ragesoss wrote:

I think I have a good guess at what happened, a race condition of sorts.

The course on the dashboard was create very soon before it was synced, and it actually started its first update very quickly, right before the sync. (This is unusual, as the update queue normally has nontrivial latency.)

My guess is that the event sync happened in the meantime, but got clobbered in the flags data structure by the update logging. I'll file an issue to make sure we fix that possibility.

A-ha! Thanks for looking into it. I'll subscribe to the upstream issue.

@vaughnwalters This task is now testable for what concerns errors being silently discarded. The original error with the P&E Dashboard can't be reproduced on-demand, but any other error will work. For example, you can first open the event page, then block yourself, then try to register. Or alternatively, open the event page, then in another window change the event to be in the past, then try to register.

What should have happened instead?:
✅ User should be able to register for the event. And if the user is unable to register, an error should display in the UI.

I can now register for this event successfully 👍

And if I am unable to register, an error is now displaying in the UI.

Sending to product sign off