Closed goatmoat closed 3 years ago
goatmoat
commented
3 years ago Upon further reading of the other issues, the issue we addressed here appears to be related to the issue highlighted in this comment: https://github.com/sjacorg/bayanat/issues/4#issuecomment-805962043. We upgraded to V1.2, but the issue remains persistent and across the board among multiple users in our group.
sjacgit
commented
3 years ago Thank you for your report. We believe this issue have been resolved already. However, if you're still having the same issues after upgrading to the latest code, can you please provide the following:
goatmoat
commented
3 years ago After upgrading to V1.3, this issue continues. Labels commit randomly, other secondary components are slightly less inconsistent, but inconsistent in terms of committing nonetheless.
It often happens when either filling in a parent label or checking some of the checkboxes (verified, actors, etc).
Errors in the server logs look like this: May 07 21:05:21 bayanat uwsgi[336440]: [pid: 336440|app: 0|req: 6/19] 127.0.0.1 () {50 vars in 867 bytes} [Fri May 7 21:05:21 2021] PUT /admin/api/label/53 => generated 4605 bytes in 31 msecs (HTTP/1.0 500) 3 headers in 215 bytes (1 switches on core 1) May 07 21:05:31 bayanat uwsgi[336440]: [2021-05-07 21:05:31,349] ERROR in app: Exception on /admin/api/label/53 [PUT] May 07 21:05:31 bayanat uwsgi[336440]: Traceback (most recent call last): May 07 21:05:31 bayanat uwsgi[336440]: File "/home/bayanat/bayanat/env/lib/python3.8/site-packages/flask/app.py", line 2447, in wsgi_app May 07 21:05:31 bayanat uwsgi[336440]: response = self.full_dispatch_request() May 07 21:05:31 bayanat uwsgi[336440]: File "/home/bayanat/bayanat/env/lib/python3.8/site-packages/flask/app.py", line 1952, in full_dispatch_request May 07 21:05:31 bayanat uwsgi[336440]: rv = self.handle_user_exception(e) May 07 21:05:31 bayanat uwsgi[336440]: File "/home/bayanat/bayanat/env/lib/python3.8/site-packages/flask/app.py", line 1821, in handle_user_exception May 07 21:05:31 bayanat uwsgi[336440]: reraise(exc_type, exc_value, tb) May 07 21:05:31 bayanat uwsgi[336440]: File "/home/bayanat/bayanat/env/lib/python3.8/site-packages/flask/_compat.py", line 39, in reraise May 07 21:05:31 bayanat uwsgi[336440]: raise value May 07 21:05:31 bayanat uwsgi[336440]: File "/home/bayanat/bayanat/env/lib/python3.8/site-packages/flask/app.py", line 1950, in full_dispatch_request May 07 21:05:31 bayanat uwsgi[336440]: rv = self.dispatch_request() May 07 21:05:31 bayanat uwsgi[336440]: File "/home/bayanat/bayanat/env/lib/python3.8/site-packages/flask/app.py", line 1936, in dispatch_request May 07 21:05:31 bayanat uwsgi[336440]: return self.view_functionsrule.endpoint May 07 21:05:31 bayanat uwsgi[336440]: File "./enferno/admin/views.py", line 187, in api_label_update May 07 21:05:31 bayanat uwsgi[336440]: label = label.from_json(request.json['item']) May 07 21:05:31 bayanat uwsgi[336440]: File "./enferno/admin/models.py", line 150, in from_json May 07 21:05:31 bayanat uwsgi[336440]: self.parent_label_id = json["parent"]["id"] if "parent" in json else None May 07 21:05:31 bayanat uwsgi[336440]: TypeError: 'NoneType' object is not subscriptable
I suspect this might also be related to the issue regarding assignment (issue #10 which I opened), but I suppose the key point here is objects not being subscriptable. In the server logs, any time I add a parent when making a new label, or amending/adding parent/check checkboxes, above error shows up in the server log.
In the UI, I get this error message (see image)
In the browser console, working on labels, I get these error messages: XHRPUThttps://bayanat.XXXXXXXXXX.net/admin/api/label/48 [HTTP/1.1 500 INTERNAL SERVER ERROR 54ms]
Error: Request failed with status code 500 axios.min.js:1210:16 XHRPUThttps://bayanat.XXXXXXXXXX.net/admin/api/label/49 [HTTP/1.1 500 INTERNAL SERVER ERROR 38ms]
Error: Request failed with status code 500 axios.min.js:1210:16 XHRPOSThttps://bayanat.XXXXXXXXXX.net/admin/api/label/ [HTTP/1.1 500 INTERNAL SERVER ERROR 148ms]
Promise rejected after context unloaded: Actor 'Conduits' destroyed before query 'RuntimeMessage' was resolved 21 content_script_bundle.js:173 action moz-extension://8704a6cb-23df-4369-8f74-963e5c9b1833/dist/content_script_bundle.js:173 XHRPUThttps://bayanat.XXXXXXXXXX.net/admin/api/label/53 [HTTP/1.1 500 INTERNAL SERVER ERROR 157ms]
Error: Request failed with status code 500 axios.min.js:1210:16 XHRPUThttps://bayanat.XXXXXXXXXX.net/admin/api/label/56 [HTTP/1.1 500 INTERNAL SERVER ERROR 37ms]
Error: Request failed with status code 500 axios.min.js:1210:16 Promise rejected after context unloaded: Actor 'Conduits' destroyed before query 'RuntimeMessage' was resolved 23 content_script_bundle.js:173 action moz-extension://8704a6cb-23df-4369-8f74-963e5c9b1833/dist/content_script_bundle.js:173 Promise resolved after context unloaded content_script_bundle.js:173 Promise rejected after context unloaded: Actor 'Conduits' destroyed before query 'RuntimeMessage' was resolved 11 content_script_bundle.js:173
Any idea what direction I need to focus on to fix this?
sjacgit
commented
3 years ago OK thanks for all this info. We're aware of this issue and a fix has already passed testing, but still not pushed to this repository. We're hoping to push the next release on Monday/Tuesday.
The issue is happening because the user searches for a parent label but doesn't add one. You can in the meantime avoid this error by making sure not to search for a parent at all when creating a label, or that a parent is added.
goatmoat
commented
3 years ago Thank you. Understood. I'll leave this issue (and the assignment issue) open for now. I think this very promising software is getting very close to operational use, but believe this crucial issue (not only the parent search function but a broader non-subscriptable object issue where new or changed objects disappear randomly) prevents it from official implementation, as it's fundamental to having system trust. We look very much forward to your updated repository!
sjacgit
commented
3 years ago Thank you for your patience. We've pushed a new version today (1.5) that should fix the issues you've been having. Can you please follow the instructions in the release to update and test to see if the issues are gone now?
goatmoat
commented
3 years ago Hello there. Thank you for your update. We had, in the meantime, upgraded to V1.4 which upon testing, had the same non-subscriptable issue persist. We will begin planning your new version upgrade immediately and will test run V1.5 as soon as possible to let you know the result. Many thanks again for your hard work on this.
goatmoat
commented
3 years ago Hi There. We upgraded to V1.5 by following the new instructions with adding the EnvironmentFile and transferring enferno/settings.py settings files to that, as well as Celery files to point to its .env. After testing on multiple accounts, this issue of non-subscriptable fields (related to parent) appears to have been resolved and both labels and locations are committing records without random failure. At the same time, we have difficulty locating the media import tool. This has now disappeared from the UI (but switch in settings file has not been added).
sjacgit
commented
3 years ago Glad to hear that the issues have been resolved now.
Regarding the media import tool, the ETL_TOOL setting in enferno/settings.py is responsible for enabling or disabling the tool. Make sure it's set to True to enable this feature. Also, make sure you didn't override the new setting file with your old one. You can try git checkout enferno/setting.py and then check the filesystem and etl tool settings in the file to make sure they are correct for your system. These two settings are the only remaining settings that should be edited in that file now, the rest of the settings should be set in a .env file and the settings.py file should only reference the settings from that file.
If that doesn't help please open a new issue for that issue and include any errors you may find in the logs.
Hello. Among our group, we have tested Bayanat rigorously and continue to encounter challenges in making the software operational. So far, we believe we cannot use it.
While the 1.2 version addressed some of the challenges we encountered with bootstrapping Bayanat on a VPS, we continue to have a persistent problem that undermine our trust in the system. Namely, that entered data sometimes does and sometimes doesn't get committed, especially with regard to secondary components. At first, these errors appeared to be random, but after a while, we saw a consistent pattern appear with the checking of checkboxes in new items in secondary components that had a much higher incidence of recording failures. These non-record-committal errors occasionally occur among primary components as well (Actors, Incidents, Bulletins), although with less consistency.
Typically, once a label/location/event type/source is added (with checkboxes checked, such as verified, bulletin etc), a label number is not associated with the listing, and the label disappears altogether after refreshing the browser.