Not all rows are rendered when there are challenges which include only a subset of tools

[dominikbruechner]

If there is a challenge, such as [G_STD_Vertebrata] OEBX002000000Y, which only includes a subset of tools, when it is selected/the link is clicked it just shows the subset https://dev-openebench.bsc.es/scientific/OEBC002/OEBX002000000Y

Once the table receives only a subset of participants, it just does not render completely (it is not robust in data handling)

Acceptance Criteria:

• Table should be robust, and also render completely if there are some challenges which only have data for a subset of tools
• This could also be achieved by adapting the bench event API to return undefined for tools which were not participating

[jmfernandez]

Could you elaborate the issue a bit more, please? Which is the offending REST query the web interface is issuing? Also, a example REST query which is still working would be helpful, in order to narrow down the divergence.

[dominikbruechner]

the rest query is this one:

curl 'https://dev-openebench.bsc.es/rest/bench_event_api/OEBE0020000002/diagonals' \
  -H 'Connection: keep-alive' \
  -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36' \
  -H 'Accept: */*' \
  -H 'Sec-GPC: 1' \
  -H 'Origin: http://localhost:4200' \
  -H 'Sec-Fetch-Site: cross-site' \
  -H 'Sec-Fetch-Mode: cors' \
  -H 'Sec-Fetch-Dest: empty' \
  -H 'Referer: http://localhost:4200/' \
  -H 'Accept-Language: en-US,en;q=0.9,de-DE;q=0.8,de;q=0.7,es-ES;q=0.6,es;q=0.5' \
  --compressed

[dominikbruechner]

What it returns:

[{
	"_id": "OEBX002000000Y",
	"acronym": "G_STD_Vertebrata",
	"participants": {
		"Domainoid+": 1,
		"Hieranoid 2": 4,
		"InParanoid": 3,
		"OMA Groups": 4,
		"OMA Pairs": 2,
		"OrthoFinder-2.5.2-MSA": 1
	}
}, {
	"_id": "OEBX0020000013",
	"acronym": "TreeFam-A",
	"participants": {
		"Domainoid+": 2,
		"EnsemblCompara (e103)": 2,
		"Hieranoid 2": 3,
		"InParanoid": 2,
		"MethaPhOrs": 3,
		"OMA GETHOGs": 3,
		"OMA Groups": 4,
		"OMA Pairs": 3,
		"OrthoFinder-2.5.2-MSA": 1,
		"OrthoInspector 3": 1,
		"OrthoMCL": 1,
		"PANTHER 16.0 (All)": 1,
		"PANTHER 16.0 (LDO only)": 4,
		"PhylomeDB V5": 4,
		"RBH/BBH": 4,
		"RSD": 4,
		"SonicParanoid": 2,
		"SonicParanoid_fast": 3,
		"SonicParanoid_most-sensitive": 1,
		"SonicParanoid_sensitive": 2
	}
}
...

[dominikbruechner]

What would be good that it returns:
(Undefined for none-participants for a challenge

[{
	"_id": "OEBX002000000Y",
	"acronym": "G_STD_Vertebrata",
	"participants": {
		"Domainoid+": 2,
		"EnsemblCompara (e103)": **Undefined**,
		"Hieranoid 2": 3,
		"InParanoid": 2,
		"MethaPhOrs": **Undefined**,
		"OMA GETHOGs": **Undefined**,
		"OMA Groups": **Undefined**,
		....
	}
}, {
	"_id": "OEBX0020000013",
	"acronym": "TreeFam-A",
	"participants": {
		"Domainoid+": 2,
		"EnsemblCompara (e103)": 2,
		"Hieranoid 2": 3,
		"InParanoid": 2,
		"MethaPhOrs": 3,
		"OMA GETHOGs": 3,
		"OMA Groups": 4,
		"OMA Pairs": 3,
		"OrthoFinder-2.5.2-MSA": 1,
		"OrthoInspector 3": 1,
		"OrthoMCL": 1,
		"PANTHER 16.0 (All)": 1,
		"PANTHER 16.0 (LDO only)": 4,
		"PhylomeDB V5": 4,
		"RBH/BBH": 4,
		"RSD": 4,
		"SonicParanoid": 2,
		"SonicParanoid_fast": 3,
		"SonicParanoid_most-sensitive": 1,
		"SonicParanoid_sensitive": 2
	}
}

[jmfernandez]

Hi @dominikbruechner , the main problem there is that there is a difference between a participant who did not send the results, and a participant who did not participate. In the first case, there should be traces in the database, but in the second, which is the case being shown in the example, the code generating each one of the objects in the returned array could only extrapolate that from the sibling result. And that predates the first case when it is happening.

So, I'm afraid the fix should be done on client side, in order to be able to identify in the future participants who did not finished in time (or gave up) from participants not involved in that challenge.

[jmfernandez]

What I can do is the provisioning to assure the case where a participant could not finish in time (or gave up) is reported as you have requested, returning a null value.

[dominikbruechner]

I think we should do both, do it properly from client side and also return an according value.
can we distinguish timeout/give up?
Do we need to specify some particular status, besides the quartile? Or is 'Undefined' good enough?