If we go straight to the WT surface using veaction=editsource, we don't bother loading the HTML document form RESTBase, which means we don't get an etag. Without an etag we can't ask for html->wikitext snippet conversions via the RB/VirtualRB.
Without an etag we can't ask for html->wikitext snippet conversions via the RB/VirtualRB.
This doesn't seem to be quite right. We send a null etag to MultiHttpClient as the if-match header, it gets converted to an empty string by a trim() call in getCurlHandle, and it still works...
The ETag is used within RESTBase to locate the exact version of data-parsoid corresponding to the original HTML you've based your edit on. In RESTBase we require an ETag to be present either in If-Match header, or inlined in HTML with meta property=mw:TimeUuid element (less desirable). If we didn't require an ETag, if the page was rerendered (for example due to a template change and Change-Prop change) in the timeframe between the original HTML was requested and the transform request was submitted, the data-parsoid versions could mismatch leading to dirty diffs and all the other problems. So, you wouldn't see the issues all the time, but they would manifest sometimes.
I don't understand the problem though - if you are in the WT editor, why would you need to call html->wikitext transform? And if you're switching to HTML editor - don't you load the original HTML? Could you please tell more about your use-case?
Yesh - if you are using wikitext mode only we fetch wikitext directly from the PHP API, because there is no RESTBase API for getting wikitext. If we switch to VE, we use the same API calls as we currently use for switching from source mode.