issues with understanding errors (might require client work)

[aurreco-uga]

(validation in https://github.com/VEuPathDB/service-multi-blast/tree/dev/lib-blast-query-parser/src/main/kotlin/mblast/query/validate)

1- blast 500 usually due to sequence issues , we dont tell user, and dont give option to fix
latest issue: initial dashes => ellie will add to validation (to the errors we show on UI about sequence validation are 422 before runnig blast)
2- param sequence regex: remove? search run breaks when defline starts with >> which is allowed by ncbi blast
3-formatter exit status 255: we show a 400 unclear json description missing message (opened issue VEuPathDB/EbrcWebSvcCommon#4)
4- service throws 400 for unclear reason since it doesnt run and it is not in the workspace (job had been run days earlier and workspace got deleted, so it is in user database) fungi e0f0861e0be42c1b88dcfeb7f3dedb28 dec 13 6:48am

[Foxcapades]

For clarification on #⁠1, the 500 is not passed to the user, the 500 is returned by the internal blast CLI container's micro-http server because the blast CLI command returned a non-zero exit code.

One of the major issues that causes the blast CLI command to fail is the fact that we previously didn't apply any validation rules to dashes in sequences, however the blast CLI tools do validate the dash count, specifically on the first line of a sequence, up to a max of 70 characters.

This has been patched on the old service by #211 and patched in the rewrite by #210

[Foxcapades]

Point #⁠2 is an issue in one or more of the site projects, the multiblast service applies no validation rules to deflines and has no regex used when parsing sequence inputs.

[Foxcapades]

Point #⁠3 is/was an issue with the multiblast plugin in EbrcWebSvcCommon. When receiving an errored job response, the site code is attempting to get the JSON property "description" from the response object, but the response object does have not and never has had a "description" property, so there must have been some confusion around the MBlast API responses when developing this plugin.

Either way, the issue has been patched on the master branch and is tracked by issue: VEuPathDB/EbrcWebSvcCommon#4

[Foxcapades]

Point #⁠4 I was unable to reproduce, I am able to access that job's results both as a guest and a logged in user.

[Foxcapades]

For point #⁠4

The log output from the old mblast service for the request that returned a 400 is (with fgputil lines trimmed out):

2022-12-13 06:42:48.578 [rid:yRSgm] DEBUG RequestLogger:33 - Request start: POST /reports
2022-12-13 06:42:48.579 [rid:yRSgm] DEBUG AuthFilter:99 - Authenticating request
2022-12-13 06:42:48.579 [rid:yRSgm] DEBUG AuthFilter:116 - Endpoint allows guest logins.
2022-12-13 06:42:48.579 [rid:yRSgm] DEBUG AuthFilter:137 - Auth token is not a user id.
2022-12-13 06:42:48.584 [rid:yRSgm] DEBUG AuthFilter:169 - Request authenticated as a registered user
2022-12-13 06:42:48.585 [rid:yRSgm] DEBUG BlastDBManager:15 - Opening connection org.gusdb.fgputil.db.wrapper.ConnectionWrapper@5a23a35a
2022-12-13 06:42:48.852 [rid:yRSgm] DEBUG BlastManager:279 - Blast workspace e0f0861e0be42c1b88dcfeb7f3dedb28 does not exist.
2022-12-13 06:42:48.853 [rid:yRSgm] DEBUG BlastDBManager:19 - Closing connection org.gusdb.fgputil.db.wrapper.ConnectionWrapper@5a23a35a
2022-12-13 06:42:48.854 [rid:yRSgm] DEBUG ErrorMapper:81 - Caught Exception: HTTP 400 Bad Request
2022-12-13 06:42:48.854 [rid:yRSgm] DEBUG RequestLogger:42 - Request end: POST /reports 400

Based on this, what I would assume the issue is is that the client got the query job back with a status of expired and decided to request a report anyway.

The 400 was caused by the fact that a report was requested for a job that didn't exist in the cache anymore (thus was "expired").