Issues after 9.x to 10.x update and fixes I had to make

Hey,

I’m on FreeBSD and typically running off tags/branches. I think I was on a fairly late 9.x tag just before 10.x started appearing. Anyway I switched to 10.0.8, no problems with the self-upgrades it does (python modules, DB schema etc), but I started noticing my integration scripts failing. I use the nzbToMedia repo for my sabnzbd to trigger a post-process call to Sickrage, and in the logs I noticed it essentially complaining about HTTP auth issues. I regenerated an API key but it still persisted.

I then had a look at the code changes and I noticed heavy work around the /api endpoint. What seemed to be issue was that the new way you added handlers for tornado wasn’t correctly extracting the API key from the url path, which is used to compare the key for access, i.e. sickrage/core/webserver/handlers/api/v1/__init__.py has if sickrage.app.config.general.api_v1_key == self.path_args[0]: - but the path_args doesn’t contain the key anymore as it wasn’t a captured group, hence this change fixed it:

diff --git a/sickrage/core/webserver/__init__.py b/sickrage/core/webserver/__init__.py
index 539b86317..68c5c1076 100644
--- a/sickrage/core/webserver/__init__.py
+++ b/sickrage/core/webserver/__init__.py
@@ -160,7 +160,7 @@ class WebServer(threading.Thread):
             sickrage.app.config.general.web_root = sickrage.app.config.general.web_root = ('/' + sickrage.app.config.general.web_root.lstrip('/').strip('/'))

         # api root
-        self.api_v1_root = fr'{sickrage.app.config.general.web_root}/api/(?:v1/)?{sickrage.app.config.general.api_v1_key}'
+        self.api_v1_root = fr'{sickrage.app.config.general.web_root}/api/(?:v1/)?({sickrage.app.config.general.api_v1_key})'
         self.api_v2_root = fr'{sickrage.app.config.general.web_root}/api/v2'

         # tornado setup

I don’t think that’s 100% ideal as the “v1” check there, if matched, would be placed into [0] I think, but you get the issue hopefully of needing that capture group for the key check as it currently is.

The second issue was my post-process script doesn’t provide a process_method param by default, which I always thought was move anyway (it is in my UI but it still resorted to copy), but it seems with your new code it defaults to copy, and that default (ProcessMethod.COPY.name) variable value is COPY (capitalized), but the param check compares against lower-case, so it complained about failing param checks. The quick fix I made for this was to simply make the default lower-case as well for the comparisons, and that got everything working again:

diff --git a/sickrage/core/webserver/handlers/api/v1/__init__.py b/sickrage/core/webserver/handlers/api/v1/__init__.py
index 86d5bcc4c..cdb70c7d5 100644
--- a/sickrage/core/webserver/handlers/api/v1/__init__.py
+++ b/sickrage/core/webserver/handlers/api/v1/__init__.py
@@ -1174,7 +1174,7 @@ class CMD_PostProcess(ApiCall):
         self.path, args = self.check_params("path", None, False, "string", [], *args, **kwargs)
         self.force_replace, args = self.check_params("force_replace", False, False, "bool", [], *args, **kwargs)
         self.return_data, args = self.check_params("return_data", False, False, "bool", [], *args, **kwargs)
-        self.process_method, args = self.check_params("process_method", ProcessMethod.COPY.name, False, "string", [x.name.lower() for x in ProcessMethod], *args, **kwargs)
+        self.process_method, args = self.check_params("process_method", ProcessMethod.COPY.name.lower(), False, "string", [x.name.lower() for x in ProcessMethod], *args, **kwargs)
         self.is_priority, args = self.check_params("is_priority", False, False, "bool", [], *args, **kwargs)
         self.delete, args = self.check_params("delete", False, False, "bool", [], *args, **kwargs)
         self.failed, args = self.check_params("failed", False, False, "bool", [], *args, **kwargs)

Everything else since the upgrade has roughly been fine, but I had to disable AniDB integration today as it was seemingly hanging the webserver threads (UI and API calls just hanging, nothing in logs, and only thing I saw in the logs was when trying to stop the server gracefully it was it hanging on closing the AdiDB connection, so figured maybe that was related).

That’s all for now, hopefully enough info to explain the issues but let me know if you need anything else.

1 Like

Thanks for this, I’ll make the corrections in the develop branch and push out

Thanks - I see they’re in 10.0.9, I’m running with that now and everything looks good.

One other issue I’m seeing though (since 9.x) is that after a time it seems the webserver (UI and API) seem to hang. It’s still doing things though (like searching for new episodes etc) as I can see activity in the logs.

I don’t see anything in the logs relating to the webserver (running with debug on) and restarting the process brings it back - so if there’s anything else I can turn on to debug why it would hang that’d be cool.

Also not sure if a bug as I feel like I may have always noticed this - but when I start up the app the webserver (UI and API) take maybe 30s to initially respond with nothing in the logs indicating why.