Controller method fails
AussieScorpio opened this issue · comments
When the controller ("/queue_job/runjob") gets called, a fatal error occurs.
Oddly, if I take the URL that it's trying to reach and replace the http://localhost:8069/ with https://my-domain/, and execute it from my browser where I'm logged in, it works. (I have Nginx acting as reverse proxy and doing SSL termination; hence the https and the use of a hostname).
If I try the same thing from a clean browser with no cookies, it fails.
The only thing that I can think of that's different is the fact that I'm a logged in user when it succeeds. This would seem to be contrary to documentation that I've read that states that it's intended for anonymous users to be able to call the controller.
Running everything locally with Odoo16 in Docker.
Am I missing something?
2023-05-01 13:24:42,269 39 INFO ? odoo.addons.queue_job.jobrunner.runner: asking Odoo to run job fb5f9379-3a40-44e9-b4bd-aa60cf212d53 on db odoo162
2023-05-01 13:24:42,336 33 ERROR ? odoo.http: Exception during request handling.
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/odoo/http.py", line 1989, in __call__
response = request._serve_nodb()
File "/usr/lib/python3/dist-packages/odoo/http.py", line 1552, in _serve_nodb
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/usr/lib/python3/dist-packages/odoo/http.py", line 1725, in dispatch
return endpoint(**self.request.params)
File "/usr/lib/python3/dist-packages/odoo/http.py", line 696, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/mnt/extra-addons/queue_job/controllers/main.py", line 41, in runjob
env = http.request.env(user=SUPERUSER_ID)
TypeError: 'NoneType' object is not callable
2023-05-01 13:24:42,337 33 INFO ? werkzeug: 127.0.0.1 - - [01/May/2023 13:24:42] "GET /queue_job/runjob?db=odoo162&job_uuid=fb5f9379-3a40-44e9-b4bd-aa60cf212d53 HTTP/1.1" 500 - 1 0.003 0.045
2023-05-01 13:24:42,338 39 ERROR ? odoo.addons.queue_job.jobrunner.runner: exception in GET http://localhost:8069/queue_job/runjob?db=odoo162&job_uuid=fb5f9379-3a40-44e9-b4bd-aa60cf212d53
Traceback (most recent call last):
File "/mnt/extra-addons/queue_job/jobrunner/runner.py", line 242, in urlopen
response.raise_for_status()
File "/usr/lib/python3/dist-packages/requests/models.py", line 943, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 500 Server Error: INTERNAL SERVER ERROR for url: http://localhost:8069/queue_job/runjob?db=odoo162&job_uuid=fb5f9379-3a40-44e9-b4bd-aa60cf212d53
Hi, I'm seeing the same behaviour in a k8s install, locally using the same image it worked flawlessly
Found a cause and a workaround, this problem seem to happen only when there are more than one db accessible to the db user, if only one db accessible for the odoo user, everything goes fine..
Found a cause and a workaround, this problem seem to happen only when there are more than one db accessible to the db user, if only one db accessible for the odoo user, everything goes fine..
I'm still to test this, but if this is the case (and it might be given a similar issue I've had in the past), that's a huge caveat missing from the module documentation and effectively renders the module useless to a large number of users. And of course some might implement, have it working fine, only to have it fail further down the track when they add a new database. This is conceivably something that could happen in production and bring a business to a halt as they rush to find out why it's stopped working.
After suffering and analyzing what happened in odoo16 and comparing against our latest installed version that is v12 we are almost sure that main culprit of this bug has more todo with core odoo changes than this module changes, almost nothing has changed in queue_job from v12 at least nothing very fundamental to the extension, instead it seems that odoo itself has changed the conditions and preparations before calling the nondb controller.. that controller gets called whenever a server with multiple db is called as the system does not select a "default" db to create a "default" env and cursor, and bang..env is none when it is needed..
In case you missed it: could you check if this change fixed it? #504
Thanks for the feedback!