thewca / worldcubeassociation.org

All of the code that runs on worldcubeassociation.org
https://www.worldcubeassociation.org/
GNU General Public License v3.0
324 stars 175 forks source link

Edits on some competitions appear to be reverting #7722

Open dunkOnIT opened 1 year ago

dunkOnIT commented 1 year ago

Email thread: "Website restored?"

Competitions affected:

Gregor's comments:

With these additional observations, the problem description suddenly makes a lot of sense to me. When the competition is created (and announced), it gets ported over to Groupifier (or WCA Live or any other third party tool that uses our APIs, for that matter) and the WCIF contains the old schedule as it is represented on the website at that point in time. Then, Ron changes the schedule on the WCA site, but the changed schedule is never communicated to Groupifier. So when he finally syncs back the group assignments to the main website, that Groupifier WCIF contains the old schedule -- which overrides Ron's changes and makes it seem like the main website "forgot" about the new schedule.

This seems like a conceptual problem with WCIF, and I'd like to brainstorm about potential solutions. From a programmer perspective, I'd simply say "keep your data in sync", but we cannot expect Delegates or any other non-tech users to understand and fully control which platform to sync when. Spontaneously, I see two potential solutions:

  • Provide more fine-grained PATCH endpoints on the main WCA website, so that you can do stuff with one section of the WCIF without affecting all of the others. Like PATCHing the schedule while leaving the competitors section unaffected. This could even be implemented by one PATCH endpoint which accepts partial WCIF (it's okay if some parts are not present, only the parts that actually are present need to match the specification exactly)
  • Implement write safeguards, so that upon every PATCH you must provide a checksum that proves you fetched the most recent version from the server before you altered and attempted to PATCH it.

I feel like similar discussions could have come up during the inception and initial design drafts of WCIF, which is why I'm pinging Jonatan specifically. But other members also by all means feel free to contribute all thoughts you might have!

Jonatan's comments:

To add some context:

  1. WCA Live stores the data from WCIF, however on every synchronization it fetches the latest WCIF and updates the stored data based on that, only then posts the new WCIF. The app only really modifies the results, so the schedule it sends should always match the WCA website. In Ron's case it sounds like many schedule details have been overridden, so I think it's unlikely that it's a synchronization bug, because if it was I think we would run into that much more often.

  2. Groupifier doesn't store data at all. When the user signs in, they load WCIF, do some changes and whenever they hit "save" the new WCIF is sent to the WCA website. On a sidenote, it doesn't refresh oauth tokens, so assuming someone keeps Groupifier open for a day for some reason, hitting "save" would result in an error (which in this case is actually a good thing).

@Gregor Billing in fact an application can already submit practical WCIF, any of the root fields can be omitted, so we can send {"schedule": ...} or {"events": ...} (ref). We could discuss more granularity, but there hasn't been a clear use case so far.

With all that said, it's actually not obvious to me where the old data would come from. One scenario that would make sense is if Ron opened Groupifier, then made some changes on the WCA website, then hit "save" in Groupifier. However, since Groupifier doesn't refresh the oauth token, this would need to happen within at most 2h, whereas from the discussion above it looks like there was a fair amount of time before the schedule was reverted. Alternatively, I can imagine someone having 2 tabs with the schedule on the WCA website (or 2 separate people), and after some time passes they modify the old schedule and save it, but this sounds pretty unlikely to me too. Either way, I don't recall similar reports in the past, so it definitely feels more like some weird usage edge case, rather than a clear bug.

jfly commented 1 year ago

This is a challenging problem =( In general, data synchronization problems like this are fundamentally hard and fully robust solutions end up looking like git :p There are some past thoughts about api design captured here, but I don't think it has any answers for the problem being discussed here.

I do think @jonatanklosko's right that it should be hard to come up with real world scenarios where these problems arise.

you must provide a checksum that proves you fetched the most recent version from the server before you altered and attempted to PATCH it

How would this interact with the API's existing support for POSTing partial WCIF?

EdHollingdale commented 1 year ago

I don't know the technical details, but we have had this happen in Australia as well - Kerrie and Ethan probably recall Melbourne Summer 2022 as the worst affected. Generally we only create the page on WCA Live the day of the comp - having it created before you do the final schedule tweaking and groups seems to cause the potential for this schedule synchronisation issue.

CarterKoala commented 6 months ago

FYI, this happened again :( . Delta County Cubing 2024 was the competition affected.

dunkOnIT commented 6 months ago

Could you define "this happened again" - was the schedule overwritten when syncing with Groupifier?

CarterKoala commented 6 months ago

Thinking back to when I was creating groups, it may have been a syncing issue with Delegate Dashboard rather than Groupifier (though I guess it's essentially the same thing?). I did not realize that that may be the potential problem.

IIRC I did things in this order:

I checked on the scorecard pdfs, and it looks like the changes are not reflected on there.

The schedule was changed recently prior to this and that change was not reverted. The only things that were reverted were advancement conditions for some rounds and a cutoff that needed to be added still.