-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
collectionviews: Ignore session state if it uses the wrong format #909
Conversation
a94375b
to
389270b
Compare
It is possible for COLLECTIONS_STATE to be populated with data from a previous version of kolibri-explore-plugin, which results in unhandled errors in new code which expects it to be in a different format. https://phabricator.endlessm.com/T35159
This view was accessing "name" and "sequence" items in the collection manager state object. These have been renamed to "collection_name" and "collection_sequence". https://phabricator.endlessm.com/T35159
389270b
to
8542bd1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a query about the new locking. If I am misunderstanding and the lock does need to be held while calling the wrapped_function, then consider this an approval.
with ENSURE_INITIATED_RLOCK: | ||
if _collection_download_manager is None: | ||
_read_content_manifests() | ||
return api_function(*args, **kwargs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it intentional that the wrapped function is called with the lock held?
IIUC, the lock is meant to ensure that _read_content_manifests()
is called only once; so I would expect that the lock could be released before calling the wrapped api_function
. But I'm probably wrong!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ooh yes, that isn't intentional. Thanks for noticing :)
It is possible for concurrent requests to be served by different threads in the same Python process, resulting in unexpected behaviour if the wrapper function from ensure_initiated is not finished executing for the first time. To solve this, wrap the critical code in a lock. https://phabricator.endlessm.com/T35159
d4db24e
to
4743786
Compare
It is possible for COLLECTIONS_STATE to be populated with data from a previous version of kolibri-explore-plugin, which results in unhandled errors in new code which expects it to be in a different format.
https://phabricator.endlessm.com/T35159