The dates tab has a lot of redundant calls to action around
upgrading to verified track. This replaces them with a single
banner at the top of the page.
AA-102
* Revert "Use pip-sync to make sure that dep cache tarball can go safely stale"
This reverts commit d435f4cd3e.
* Revert "Extract worker setup into own shell script, as much as possible"
This reverts commit 0a079e757c.
These removed tests can be restored once someone works out why they
were causing flakiness elsewhere and fix the problem.
Reverts tests added in:
dca50aacc3
The cache in the previous version of this code was unwittingly being
shared among all threads, and an occasional race condition would result
in the .children field of some XBlocks containing duplicate entries.
I tried to find other ways to keep the existing cache design and let it
be shared among all the threads (which would be more efficient), but I
couldn't find any clean way of doing it (and even then, this code was
not written with the intention of being used in a multi-threaded way).
So to keep the fix simple, I made the block data cache thread-local
instead of process-local. That eliminated the bug.
Technical details:
The big challenge with this code in the first place was due to the
parse_xml API of XBlocks, which instantiates the XBlock instance and
_then_ sets field data on it and returns it, as there is no mechanism
available to distinguish that from the case of instantiating an XBlock
(using previously loaded/cached field data) and then deliberately
changing its field values. In particular, parse_xml sets the 'children'
field just by calling self.children.append(...) but never explicitly
initializes self.children to [] first, so it's necessary for the field
data store to have a mechanism for setting self.children = [] when
parsing begins, but it's hard to know "when parsing begins" in general.
This is made more challenging since the BlockstoreFieldData design ties
field data changes to the XBlock instance itself (using a weakkey), but
it's impossible to get a reference to the XBlock instance before calling
parse_xml, and since the BlockstoreFieldData design uses a pass-through
approach where fields that aren't being actively changed are read from
the cache; since it doesn't know when children is being initialized vs.
being modified, it would sometimes pass-through and start one thread's
changes with the final result from another thread.
Anyhow, the bottom line is that avoiding unintentional multithreading
here solves the problem.
If we want the field data cache to be shared among threads, it might as
well be rewritten to use memcached and shared among all processes too.
That would be a very good performance boost but would take up a lot more
memory in memcached. Also the rewrite may be challenging due to the
aforementioned nuances of the XBlock parse_xml / construct_xblock /
add_node_as_child APIs. Perhaps modifying the runtime to use a
completely separate fielddata implementation for parsing vs. loading a
parsed+cached XBlock would do it.
Created sorting for email field
updated tests
Fixed sorting issue in registration form
Fixed sorting issue in registration form
Fixed sorting issue in registration form
Added missing items in env and updated order logic
Added missing items in env and updated order logic
In the course outline, if a subsection has any graded content,
show a graded icon (the pencil icon).
Also, show the graded icon for LTI xmodule units (xblocks is a
different repo, but will get same treatment).
AA-75
