Plan:
- Update deposit server with the fix (0.9.0)
- Investigate current error when trying out 1 rescheduling... [1]
[1] https://sentry.softwareheritage.org/share/issue/4d1ddb426e164980a15499cb3e04faba/
Related to T2906#55468
Plan:
[1] https://sentry.softwareheritage.org/share/issue/4d1ddb426e164980a15499cb3e04faba/
Related to T2906#55468
Investigate current error when trying out 1 rescheduling...
[1] https://sentry.softwareheritage.org/share/issue/4d1ddb426e164980a15499cb3e04faba/
subsided after vlan migration got finished.
Update deposit server with the fix (0.9.0)
currently stuck in jenkins, going there now.
currently stuck in jenkins, going there now.
bypassed a bit the error, finally being able to deploy the 0.9.0 (grafana tagged).
The end of the build fails somehow (irrelevant to this [1]).
[1] T2927
Now, retrieve the deposits stuck in limbo (because they were actually mostly bad in their input and 0.8.0 did not catch those):
Retrieve the check_task_id required:
softwareheritage-deposit=> select id, check_task_id from deposit where status = 'verified' and client_id=7 and status_detail is null order by id desc; # 7: ipol (only those somehow)
Then make those be rescheduled:
update task set status='next_run_not_scheduled', next_run=now() where id in (349909265, 349894184, 349894059, 349893827, 349893599, 349893224, 349892342, 349890517, 349889728, 349889485, 349885320, 349884976, 349874540, 349825549, 349819087, 349818902, 349817933, 349816730, 349815684, 349815272, 349814915, 349803013, 349765073, 349642432, 349641802, 349641629, 349641415, 349641126, 349640437, 349607225, 349607007, 349573507, 349573111, 349571990, 349383345, 349383092, 349382822, 349380699, 349376837, 349376519, 349368428, 349367632, 349367244, 349340259, 349340232, 349339288, 349339055, 349320398, 349319878, 349317772, 349316155, 349315353, 349314451, 349313295, 349313072, 349310756, 349310549);
Wait a bit for the checks and the loads to kick in:
softwareheritage-deposit=> select id, check_task_id from deposit where status = 'verified' and client_id=7 and status_detail is null order by id desc; id | check_task_id ----+--------------- (0 rows)
And expectedly some are rejected with the "new" reason about invalid date format:
softwareheritage-deposit=> select id, status, status_detail, client_id from deposit where status='rejected' and client_id=7 order by id desc limit 10; id | status | status_detail | client_id ------+----------+----------------------------------------------------------------------------------------+----------- 1367 | rejected | {"metadata": [{"fields": ["codemeta:dateCreated"], "summary": "Invalid date format"}]} | 7 1361 | rejected | {"metadata": [{"fields": ["codemeta:dateCreated"], "summary": "Invalid date format"}]} | 7 1360 | rejected | {"metadata": [{"fields": ["codemeta:dateCreated"], "summary": "Invalid date format"}]} | 7 1359 | rejected | {"metadata": [{"fields": ["codemeta:dateCreated"], "summary": "Invalid date format"}]} | 7 1358 | rejected | {"metadata": [{"fields": ["codemeta:dateCreated"], "summary": "Invalid date format"}]} | 7 1356 | rejected | {"metadata": [{"fields": ["codemeta:dateCreated"], "summary": "Invalid date format"}]} | 7 1354 | rejected | {"metadata": [{"fields": ["codemeta:dateCreated"], "summary": "Invalid date format"}]} | 7 1350 | rejected | {"metadata": [{"fields": ["codemeta:dateCreated"], "summary": "Invalid date format"}]} | 7 1348 | rejected | {"metadata": [{"fields": ["codemeta:dateCreated"], "summary": "Invalid date format"}]} | 7 1347 | rejected | {"metadata": [{"fields": ["codemeta:dateCreated"], "summary": "Invalid date format"}]} | 7 (10 rows)