We never a DatabaseThreadItem back into the database. If someone
wants to do this in the future they should be thinking very
hard about it first.
Change-Id: Ie073c030905e31d81cb75bc9c46d5bb7c5d85b04
This appears to reference the retry that happens due to
REPEATABLE_READ, but that seems like an implementation
detail so not really useful to have in in the function
name, nor does it disambiguate it from another function.
Change-Id: Iacc95b74f25c166545734818efb1b30e18a1754e
This was intended as a temporary config to facilitate a
staged rollout (T331635) which has now completed.
Change-Id: I432ec0a24b8e8c12b62556ff6703abff32a2fced
When rebuilding expected outputs by running the tests with
'DISCUSSIONTOOLS_OVERWRITE_TESTS=1', our code outputs the
JSON keys in a specific order (not alphabetical).
Change-Id: Ice57948ef1d4b780ae18cfcbb2e7373f518c8abc
This is still an experimental feature and not deployed
anywhere, but as we mute the timestamp to indicate it
is more part of the interface than the content, we should
do the same with this overflow menu button.
Change-Id: I30391912377692fffa9e67e8c4ca63db715878bf
In certain cases the parser could go back rather than forward after
finding a signature, causing it to find the same signature forever
until it ran out of memory.
Test cases coming later in a separate patch.
Bug: T356884
Change-Id: I8ac72b05e5e4ed45e6119c012a69708c9d8eda29
Follow-up to 8a8c7270cf.
I think this wasn't working becase we were doing it in the wrong
order (reply tool initialization would disable toggling section
state before toggler toggled it open).
Bug: T338920
Change-Id: I7ed3d5c149ddb3d33cb67010f032c63e175687f2
* Keep the information about this in the API result, which we were
previously omitting
* Use it instead of duplicating the logic client-side
Bug: T356131
Change-Id: I7e7342e9d94a171b5ef56e646871c18c8c39c44c
`decodeURI( fragment )` can throw if the fragment isn't correctly
encoded – e.g. when it's just '#%'.
Use mw.util.percentDecodeFragment() instead, which uses a more
resilient algorithm.
Change-Id: I8447771ad2ae33da52b71d4127981dd8a2018a7d
In production, indexing the full history of every page will take
too long, so we can't rely on being able to find the target heading
text in the history of the current page.
When this search fails, fall back to the following searches:
* The heading appears in the current revision of a sub-page
* The heading appears anywhere on the wiki, but only once
Bug: T356276
Change-Id: I90e92cb9c85aaf6fb2355f842450981bbe6abf2d
