[15:40:12] MatmaRex: duesen: I see that VE edit stashing stats disappeared, I'm guessing this is related to how we now use Parsoid/Restbase directly - https://grafana.wikimedia.org/d/000000249/edit-stash?orgId=1&from=now-1y&to=now [15:40:57] Can you confirm that edit stashing is still a thing from VE's perspective, and which API it uses now? I imagine it doesn't use the same external API as wikitext given that VE doesn't have access to it client-side. [15:43:54] Ya, a bunch of metrics disappeared once VE stopped using the API. I filed https://phabricator.wikimedia.org/T339365 for the metrics that disappeared on the Parsoid end. [15:47:46] Krinkle: stashing is still a thing. It's implemented in core and triggered from VE's action API modules. It's backed by main stash (x2 databases). You can see the relevant metrics if you scroll down on the VE backend health dashboard: https://grafana-rw.wikimedia.org/d/OxxOv5K4k/ve-backend-health [15:48:23] The stashing functionality in RESTbase should be unused now. We should probably delete it... [15:49:04] duesen: to confirm, I am not referring to the "stash" that restbase dealt with, which is about the base revision that the edit starts with. I am referring to the save time optimisation where we speculatively start parsing while the edit summary is being typed. [15:49:46] duesen: oh, in that case, no idea. I am not aware that VE was even doing that. I didn't touch the relevant code in a while. [15:50:22] In MediaWiki Action API, after VE gets the result from Parsoid, it goes through EditPage etc with wikitext. We can skip parsing there if the pre-save stash is still up to date and fresh enough. [15:50:26] It's also backed by main stash, but that shouldn't be relevant [15:50:47] Afaik there does not exist a way to change where that is read from [15:50:53] it's always memcached based, same as for wikitext edits. [15:52:10] When you tell MW to save a revision, it hashes a bunch of inputs and checks whether there is an entry in the EditStash, which is based by Memc. It can be stashed there either from client-side via ApiStashEdit, or directly in PHP as VE's Action API module did/does. [15:53:14] Hm, you are right, looking at the wiring for PageEditStash, it uses ObjectCache::getLocalClusterInstance() [15:55:10] Krinkle: I see code in VE for writing to the stash, but none for reading from it. [15:55:30] DerivedPageDataUpdater seems to be the only caller of checkCache [15:55:39] yeah, that sounds right [15:55:45] it wouldn't need to read from it, that's core's responsibility [15:56:24] hm.... I guess. [15:56:51] Ok, so, it looks like this would be paction=serializeforcache [15:58:37] Turnilo finds not matches [15:58:43] So VE client coe is not hitting it [15:58:58] https://codesearch.wmcloud.org/deployed/?q=serializeforcache&files=js%24&excludeFiles=&repos= [15:59:22] I can't think of a way that this would be related to the parsoid work, but who knows... maybe MatmaRex can shed some light [15:59:52] Krinkle: i thought that that was only ever implemented for the old wikitext editor [16:00:34] (afk) [16:01:06] nope, afaik it's been the case ofr years when you press "Publish…" in VE that we start parsing in the background. VE's API module starts invoking restbase/parsoid and then further the parser for on wikitext. And then for the final save, the parser and abusefilter etcv are all done and we just create the revision basically. [16:01:14] MatmaRex: I see this.prepareCacheKey( this.getDocToSave() ) in ve.init.mw.ArticleTarget.prototype.showSaveDialog [16:01:24] No idea if that means anything :) [16:03:15] hm... the code in prepareCacheKey aborts if the mode is "source". Shouldn't it abort if the mode is *not* source? [16:03:41] anyway, I'll leave you to it, i know nothing about the client side code [16:19:55] duesen: no, "source" refers to the "2017 wikitext editor" aka "VisualEditor toolbar but with a wikitext text area", which is fairly new/opt-in and would need to communicate with the core editstash API which hasnt' been done yet. It basically isn't from a backend perspetive. [16:20:26] when you're in visualmode, stashing is most valuable since you have to wait for two parsers to complete sequentially, that's what it was made for originally. [16:21:28] plus, it's only in visual editor that we have a clear distinction in the UI between editing content and finalising your edit with the edit summary mode. the wikitext editor (core's edit page + optional WikiEditor extension toolbar) on the other hand presents these together so it's a fairly weak signal at best [16:21:49] https://www.mediawiki.org/wiki/Editor for an overview of different edits and their funky names [16:28:33] Krinkle: duesen: the "cache" and "stash" in that code refers to just the restbase (or parsoid now) stash, not the wiktiext stash you're talking about. (probably) [16:30:03] or maybe you're right and i'm wrong. it's really silly we use the same word for these two things [16:30:32] anyway, it looks like they disappeared from the dashboard 7 months ago, so probably not related to duesen's work [16:32:55] MatmaRex: I just checked, packtion=serializeforcache is for populating PageEditStash, as Krinkle said. It's unrelated to parsoid's html2wt stashing. [16:35:44] If it disappeared, that does sound like an accident... [16:39:48] If you haven't used the Excimer UI option in WikimediaDebug yet, this would make for a good use case. Eg enable it then open VE somewhere on a sandbox page, and go through the edit flow, pausing few seconds while typing the edit summary, and check what requests we got and whether it ended up re-parsing or not. Possible also enable verbose Logstash and preserve network log in browser devtools [16:40:11] I'm more worried about the perf than the perf stats :) [17:24:03] duesen: where in turnilo did you search? These are post requests which I think don't have the action=visualeditoredit part indexed. [17:26:13] when editing https://www.mediawiki.org/wiki/Project:Sandbox with VE, I get these two requests: 1. on "publish" for the edit summary modal https://performance.wikimedia.org/excimer/profile/f9a9ac8e9e965dd5 and 2. on actual submission https://performance.wikimedia.org/excimer/profile/18f0a0836939f17c [17:26:48] #1 is, I'm assuming, action=visualeditoredit paction=serializeforcache, given the call to edit stash. [17:28:43] #2 presumably … paction=save, given the revision insert. however I don't see it hitting the edit stash unfortunately. It coudl be that it's faster than the 1ms profiling interval, but given that getParserOutput is there with a Parser call, Im guessing that's a full parser invocation. [17:30:07] ah no, it is! It's tucked under saveWikitext, it's there [17:30:16] the parser is for returning the metadata back to VE [17:30:33] which is unfortunately not able to re-use the same PO, I'm guessing that's because I have a non-default user preference or something else non-canonical. [17:30:45] ok, so it's all working and fast, but we lost stats