Resolves a long standing type error in the GraphQL API.
The original type for the odds_ratio field of the contingency_table_test of the joint frequency data's frequency comparison stats (used for the discrepant frequencies flag) was a Float. However, some small percentage of the odds_ratio values were infinity, there could be several infinities in this array for a given variant due to odds_ratio being calculated for differing genetic ancestry groups.
These GraphQL errors likely had extremely little impact on users, as the gnomAD browser's frontend was requesting, but not actually using, the odds_ratio data, instead preferring a different field to display a relevant p_value. The only users who would have been impacted by this would have been those using our API, and who had requested and used the odds_ratio field of in the frequency comparison stats. I believe those users would have had a null returned to them, rather than an infinity.
This PR addresses this with 2 minor edits:
Changes the type that was previously a float to a string. This is a bit odd since some large percentage of these values are truly floats, but due to the existence of a more useful field for seeing at a glance the values relevant to discrepant frequencies (stat_union) I believe this quick fix is appropriate.
Removes the unused values from the frontend's API request. These were left in there after the stat_union field was added, and while requested, the frontend does not use the data at all.
Resolves a long standing type error in the GraphQL API.
The original type for the
odds_ratiofield of thecontingency_table_testof the joint frequency data's frequency comparison stats (used for the discrepant frequencies flag) was aFloat. However, some small percentage of theodds_ratiovalues wereinfinity, there could be several infinities in this array for a given variant due toodds_ratiobeing calculated for differing genetic ancestry groups.These GraphQL errors likely had extremely little impact on users, as the gnomAD browser's frontend was requesting, but not actually using, the
odds_ratiodata, instead preferring a different field to display a relevantp_value. The only users who would have been impacted by this would have been those using our API, and who had requested and used theodds_ratiofield of in the frequency comparison stats. I believe those users would have had anullreturned to them, rather than aninfinity.This PR addresses this with 2 minor edits:
floatto astring. This is a bit odd since some large percentage of these values are truly floats, but due to the existence of a more useful field for seeing at a glance the values relevant to discrepant frequencies (stat_union) I believe this quick fix is appropriate.stat_unionfield was added, and while requested, the frontend does not use the data at all.