Crosstable with "[Error-unknown]" players.

Noticed a recent crosstable that has several players listed with the name “[Error-unknown]”. What does this mean?

uschess.org/msa/XtblMain.php?202205290602

It’s not showing it now, so it must have been a temporary database issue.

Look at players number 7 and 20. It still says “[Error-unknown]”.

Looks like a valid bug to report. 30613703 can be searched for in the search by players scree (with the name) but when trying to link to MSA it does not come up with a name.
I thought there was some announced maintenance being done so this may be related to that.

It means that ID isn’t the the database that MSA uses. An MSA update run happens about every five minutes, but if there was a major database update it might not get to the new IDs right away.

Another possibility is that the ID was changed manually in the event by the ratings department and an invalid ID was used. But that usually leaves breadcrumbs.

I can’t do anything about it at this time.

I reported this update failure to the ratings staff and the ID has been updated on MSA manually. In general, I would recommend giving missing ID issues on MSA a day or two to allow the synchronization to get caught up and then send them to the ratings department to be updated manually.

Just to clarify—there is a membership database that MSA taps into. The MSA itself might get updated (and updated several times) before that membership database gets caught up with it. Is that the sequence here?

The primary membership database is the one that Civi-CRM uses.

MSA is refreshed directly from the Civi-CRM system, there’s a job that runs every five minutes. But it can fail to update a record on MSA and it will only do a set number of records in each pass. (1000, I think.) US Chess staff have the ability to force an update of a member’s MSA record from Civi-CRM, which is what was done to correct this situation.

Both Civi-CRM and MSA use MySQL.

The ratings programming uses PostgreSQL. There is a materialized view that has most of the fields from the membership table we used before Civi-CRM took over membership management. That way we didn’t have to rewrite any of those programs. (There are still dozens of them in use.)

That materialized view is refreshed twice a day from the Civi-CRM server, but the ratings programming, specifically the program that validates events before TDs submit them for rating, can also access the Civi-CRM data directly and will do so if a member record isn’t present or isn’t current.

Any time we refresh one database from another, that has to be done via a network connection, since the databases are in 3 different data centers. Network issues are probably behind most update failures.

This topic was automatically closed 730 days after the last reply. New replies are no longer allowed.