Align WCIF statuses with registration statuses

[dunkOnIT]

WCA Live and TNoodle throw fatal errors [comp doesn't import, scrambles don't generate] if a non-accepted/deleted/pending status is provided in the WCIF. While this is technically in line with the WCIF spec, I believe they should error out more gracefully. This would allow us to update the WCIF spec without having to coordinate releases of other software tools.

[gregorbg]

I disagree. The WCIF spec specifically exists to make sure that you deterministically figure out "Does this JSON adhere or not".

Also, it is hard to define what "Error out more gracefully" means. If there is something outside of the WCIF spec, then the programs like TNoodle just cannot continue. We would have to diligently mark individual fields as "Very strict, and catastrophic if it doesn't adhere to spec" (for example, if the number of rounds becomes a string literal, TNoodle by definition cannot generate scrambles no matter how "graceful" it errors) or "not so strict, ignore if the value doesn't match the enum". But actually, the definition of which fields are critical and which fields are "not so important" depends on the individual program.

So our best choice is still to be strict about "adheres" or "doesn't adhere, stop processing".

[dunkOnIT]

On erroring gracefully: I specifically mean that if a non-WCIF-spec status is received, the tools should skip/stop processing the offending entry, but continue processing the WCIF. ie, a non-WCIF status should not produce a fatal error.

I agree that in many/most cases, WCIF spec changes should error loudly.

I am talking myself around to agreeing that using WCIF inherently means that we have to have coordinated/versioned releases in order to update the spec, though.

[dunkOnIT]

Perhaps we should have a /wcif/{version-number} parameter which allows us to serve versioned WCIF to tools that make use of it? That puts the burden of updating onto the tools, instead of on the monolith to coordinate releases with downstream tools

[gregorbg]

Yes, we definitely need to evolve WCIF and that means serving them through a version parameter.

Re graceful error: The notion of "skip this one erroneous entry, continue processing the rest" is based on the assumption that the program consuming WCIF is proceeding entry by entry, iterating over some array. What if a non-array part of the WCIF is defective? Then it's definitely impossible to continue processing.

Also, "skipping" a defective entry will be much more catastrophic than hard crashes because it leads to unexpected and potentially even non-deterministic results. Imagine that Groupifier skipped registration entries that it cannot parse. Either, it silently skips them and half of the competitors end up without assignments which leads to disaster on the day of the competition. Or it skips them and tells the organizer that X competitors have been skipped because of WCIF errors, which will send them straight to us because of course they want all competitors assigned and so we are the ones who have to make sure that we supply the data in a format that Groupifier can process.

And that format is called WCIF.