Getting server traceback when trying to check job status

[wlupton]

I'm getting this when trying to check the status of a job (I've added some whitespace). I have previously done this without auth, so I tried with a username/password but it didn't make a difference.

% curl -s https://yangcatalog.org/api/job/adddca12-a6ba-40de-ac3f-240331a3febc
{"info":{
 "job-id":"adddca12-a6ba-40de-ac3f-240331a3febc",
 "reason":"Traceback (most recent call last):\n
File \"/backend/lib/python3.10/site-packages/celery/app/trace.py\", line 412, in trace_task\n
    R = retval = fun(*args, **kwargs)\n
  File \"/backend/lib/python3.10/site-packages/celery/app/trace.py\", line 704, in __protected_call__\n
    return self.run(*args, **kwargs)\n
  File \"/backend/jobs/celery.py\", line 110, in process\n
    celery_app.reload_cache()\n
  File \"/backend/jobs/celery.py\", line 73, in reload_cache\n
    requests.post(f'{self.yangcatalog_api_prefix}/load-cache', auth=self.confd_credentials, headers=json_headers)\n
  File \"/backend/lib/python3.10/site-packages/requests/api.py\", line 115, in post\n
    return request(\"post\", url, data=data, json=json, **kwargs)\n
  File \"/backend/lib/python3.10/site-packages/requests/api.py\", line 59, in request\n
    return session.request(method=method, url=url, **kwargs)\n
  File \"/backend/lib/python3.10/site-packages/requests/sessions.py\", line 575, in request\n
    prep = self.prepare_request(req)\n
  File \"/backend/lib/python3.10/site-packages/requests/sessions.py\", line 486, in prepare_request\n
    p.prepare(\n
  File \"/backend/lib/python3.10/site-packages/requests/models.py\", line 372, in prepare\n
    self.prepare_auth(auth, url)\n
  File \"/backend/lib/python3.10/site-packages/requests/models.py\", line 603, in prepare_auth\n
    r = auth(self)\n
TypeError: 'list' object is not callable\n
","result":"Failed"}}

[richardzilincikPantheon]

Thanks for the report, this is indeed an issue on our side, not related to if you include auth in your request.

[wlupton]

Thanks. Maybe unrelated, but the impact analysis is currently behaving strangely for me. Some modules are not found (they show in the menu and can be selected, but they fail to load). Other modules are found. Could there be a problem with modules that are currently being updated via the above job? Let me know if you'd like specific examples.

[richardzilincikPantheon]

Impact analysis shouldn't be affected, so this is likely an unrelated issue. Please open another github issue for this with the examples if possible.

[wlupton]

Created #789.

[wlupton]

I now see this:

% curl -s https://yangcatalog.org/api/job/adddca12-a6ba-40de-ac3f-240331a3febc
{"info":{"job-id":"adddca12-a6ba-40de-ac3f-240331a3febc","reason":"","result":"In progress"}}

Is it truly still in progress or do I need to resubmit the job?

And if I resubmit the job (and it completes successfully), will the impact analysis (ref. #789) now work?

Actually, it seems that all jobs show as being in progress. I tried a few fake UUIDs and they all gave the same result. For example:

% curl -s https://yangcatalog.org/api/job/deadbeef-dead-beef-dead-beefdead
{"info":{"job-id":"deadbeef-dead-beef-dead-beefdead","reason":"","result":"In progress"}}

[richardzilincikPantheon]

Is it truly still in progress or do I need to resubmit the job?

This is because the results for job runs aren't kept indefinitely. The task failed on a cache refresh after the data was processed. This means you don't need to rerun the job and the data has been added to YANG Catalog databases, but until we deploy a fix, https://yangcatalog.org/api/search/modules, https://yangcatalog.org/api/search/vendors (endpoints that send YC's complete databases of module/vendor info and pull their responses from the cache) and a few other endpoints will not reflect the new data. If it would be helpful, we could trigger a cache refresh manually this time.

And if I resubmit the job (and it completes successfully), will the impact analysis (ref. https://github.com/YangCatalog/backend/issues/789) now work?

No, the impact analysis problem is unrelated. We've found its root cause and are working on a fix, we'll post an update soon.

Actually, it seems that all jobs show as being in progress. I tried a few fake UUIDs and they all gave the same result.

Yes unknown job ID's will be reported as in progress, this is expected and a limitation of the task queue library we use.

[wlupton]

If it would be helpful, we could trigger a cache refresh manually this time.

No need, if it'll happen anyway within a few days. Thanks.