Hi @EricKriener
@AndrewTurner forwarded this to my attention. I did some additional investigation into this issue. My observations are that a 404 is not observed when navigating to the event's page when clicking a link to the event's page within the Hub application, but a 404 is observed when attempting to navigate directly to the URL of the event's page.
Upon debugging our application, it appears that Andrew's suspicion is correct; there were multiple events created with the same title. When an event is created, Hub generates a "slug" for the event (a user-friendly URL segment, derived from the event's title). A bug exists today where depending on a combination of the user creating the event and what access (public, org, private) is selected when creating/publishing the event, a duplicate slug can be generated that conflicts with slugs of other previously created events.
In your case, the event in question has a duplicate slug and upon navigating directly to the event's page, the wrong event record is actually being fetched. The event record that is incorrectly fetched is associated with a different site than the gosarpy.com site, which then results in the 404 that's observed.
Unfortunately, simply resaving the event with a different title doesn't regenerate the event's slug. My guidance to you would be to delete the duplicate events that are resulting in a 404 error and recreate them with a title that contains some unique text so the subsequently generated slug is guaranteed to be unique.
It's worth noting that the Hub team has been working diligently on a new version of our events feature which includes a number of improvements in contrast to our current events offering, including a fix for this known limitation/issue. Work is nearly completed on that project and we expect to release it to the public in 2025.
