Job composer Sorry, but something went wrong

Get Help
1

One of my users just hit this message opening the job composer
We’re sorry, but something went wrong.
If you are the application owner, check the logs for more information.

I didn’t find much in the logs, but empirical testing shows removing
/home/u23/ric/ondemand/data/sys/myjobs/production.sqlite3
makes the error go away. I saved the “bad” version of the file, if it is of any value.

Do you have suggestions less destructive ways to resolve this error?

2

You can repair and replace the DB file, but you do have to do this manually. Note the ‘repair’ functionality is new, so you’d need something like a container to do it (or a --user pip installed version) depending on your system.

Here’s a stackoverflow for how that’s done.

3

Thanks Jeff:
The database appears fine to sqlite, but that started me down the right path. It appears that it’s a "content of DB problem " rather than a “structure of DB” problem. The “Sorry, but something went wrong” is always preceded in the nginx error log with
App 11153 output: [2020-08-04 11:10:57 -0700 ] DEBUG “\e[1m\e[36mWorkflow Load (4.3ms)\e[0m \e[1m\e[34mSELECT “workflows”.* FROM “workflows” INNER JOIN “jobs” ON “jobs”.“workflow_id” = “workflows”.“id” WHERE “jobs”.“status” IN (?, ?, ?, ?)\e[0m [[“status”, “H”], [“status”, “Q”], [“status”, “R”], [“status”, “S”]]”
App 11153 output: [2020-08-04 11:10:57 -0700 ] DEBUG “\e[1m\e[36mWorkflow Load (3.9ms)\e[0m \e[1m\e[34mSELECT “workflows”.* FROM “workflows”\e[0m”
App 11153 output: [2020-08-04 11:10:57 -0700 ] DEBUG “\e[1m\e[36mJob Load (5.3ms)\e[0m \e[1m\e[34mSELECT “jobs”.* FROM “jobs” WHERE “jobs”.“workflow_id” IN (?, ?, ?)\e[0m [[“workflow_id”, 1], [“workflow_id”, 2], [“workflow_id”, 3]]”
App 11153 output: [2020-08-04 11:10:57 -0700 ] INFO “method=GET path=/pun/sys/myjobs/ format=html controller=WorkflowsController action=index status=500 error=‘ActionView::Template::Error: no implicit conversion of nil into String’ duration=23.30 view=0.00 db=13.55”

The DB dump is only 25 lines (~3k bytes). I can send that if it would be useful.

4

We’re likely going to have to remove the problematic row. You can share it if you like, directory structures are the most sensitive items in it. I think we may have ran into something similar in this GH issue on a similar issue, you can upload it either here or there.

5

Here’s a link to the text dump of the DB since this site disallows uploading test files…
sqlite “.dump” of problematic database

6

This dump was very helpful. I imported and developed against it, adding guard clauses to the problematic parts of the code. Now this edge case is handled gracefully. Note: I will open a separate issue to track how we can get records into this state in the first place - it seems like we are not capturing and reporting or handling an error as we should.

This fix will be in 1.8. I’ll also investigate to see if it is easy to add into a patch release for 1.7.

7

Thank you Very Much!!