If this comes back, please feel free to reopen.

@Eevans Do want to move this along or has it stalled?

Change 459245 had a related patch set uploaded (by Daimona Eaytoy; owner: Daimona Eaytoy):
[mediawiki/extensions/AbuseFilter@master] Add normalizeThrottleParameters script to update.php

Change 520287 abandoned by Mholloway:
Add monitored spec x-amples for Beta Cluster requests

Change 520286 merged by jenkins-bot:
[mediawiki/services/recommendation-api@master] Descriptions: Get suggestions from a Beta Wikipedia for BC requests

Change 520270 merged by jenkins-bot:
[mediawiki/services/recommendation-api@master] Stop hard-coding prod request domain for language variant request

Change 520287 had a related patch set uploaded (by Mholloway; owner: Michael Holloway):
[mediawiki/services/recommendation-api@master] Add monitored spec x-amples for Beta Cluster requests

Change 520286 had a related patch set uploaded (by Mholloway; owner: Michael Holloway):
[mediawiki/services/recommendation-api@master] Descriptions: Get suggestions from a Beta Wikipedia for BC requests

Change 520270 had a related patch set uploaded (by Mholloway; owner: Michael Holloway):
[mediawiki/services/recommendation-api@master] Stop hard-coding prod request domain for language variant request

Mentioned in SAL (#wikimedia-operations) [2019-05-13T11:43:54Z] <reedy@deploy1001> Synchronized php-1.34.0-wmf.4/extensions/VisualEditor/: T222639 (duration: 00m 52s)

Change 508867 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@wmf/1.34.0-wmf.4] ArticleTargetLoader: Add stash=true query param to RB HTML fetching

Change 508867 had a related patch set uploaded (by Mobrovac; owner: Mobrovac):
[mediawiki/extensions/VisualEditor@wmf/1.34.0-wmf.4] ArticleTargetLoader: Add stash=true query param to RB HTML fetching

Change 508518 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] ArticleTargetLoader: Add stash=true query param to RB HTML fetching

@Pchelolo @Esanders Gerrit 508518 is ready to go now. Given that the RESTBase side for supporting this is already in place in production, could we SWAT this on Monday? Doing so would allow us to continue with deploying the next step for RESTBase.

In T222639#5164284, @ssastry wrote:

Yes, if you have exact render data-parsoid send (a) modified html (b) matching old html data-parsoid ... this is what you do now.
If you don't have exact render data-parsoid, only send modified HTML and nothing else

If you don't have data-parsoid, then old HTML is useless since old html matching data-parsoid is used for selective serialization. If not, just modified HTML is used for regular normalizing serialization.

In T222639#5163458, @mobrovac wrote:

@ssastry @Arlolra so the TL;DR is: if we have the exact render data-parsoid, send it, otherwise just send the modified HTML. Is that assessment correct?

Change 508518 had a related patch set uploaded (by Mobrovac; owner: Mobrovac):
[mediawiki/extensions/VisualEditor@master] ArticleTargetLoader: Add stash=true query param to RB HTML fetching

@ssastry @Arlolra so the TL;DR is: if we have the exact render data-parsoid, send it, otherwise just send the modified HTML. Is that assessment correct? Note that if we don't have the exact render data-parsoid, we will not have the exact HTML render either to send.

In T222639#5160906, @Pchelolo wrote:

(b) so, should we send no data-parsoid entirely, or send 'whatever we have even if not matching'?

(a) this should actually be documented in the API docs (swagger?) alongwith the implications of what happens if a client doesn't comply

@Pchelolo: this doesn't just affect VE but all Parsoid clients that might fetch html for editing and might then post edited html for save. So, couple of comments (a) this should actually be documented in the API docs (swagger?) alongwith the implications of what happens if a client doesn't comply ... which brings me to the next point (b) if data-parsoid is missing, we should make sure RESTBase sends data that Parsoid serializes correctly ... the output should still be correct but it may be normalized (and hence cause a dirty diff).

In T178839#5144895, @mobrovac wrote:

@Eevans @fgiunchedi is there a plan to resume this work or should we close this ticket? Do we still want the newer jvm-tools version? I assume so, hence setting as stalled.

@Eevans @fgiunchedi is there a plan to resume this work or should we close this ticket? Do we still want the newer jvm-tools version? I assume so, hence setting as stalled.

Stalling as per Alex' and Filippo's comments.

[Blocked means stalled task status](https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle) hence setting that.

Blocked until a reply from @Kaldenderfer to answer our questions.

In T132632#5023911, @Eevans wrote:

In T132632#5023075, @mobrovac wrote:

@Eevans @fgiunchedi should we go ahead with this?

I don't think there was ever any controversy over whether we should do this. AFAIK, it didn't happen because it wasn't obvious (to me at least) how, and because of a general lack of time (or relative priority, etc).

In T132632#5023075, @mobrovac wrote:

@Eevans @fgiunchedi should we go ahead with this?