[19:54:21] coreyfloyd: hey, what are the grayed out X's and ?'s in the PCS APIs spreadsheet? [19:54:29] should i implement those or are they TBD? [20:12:18] mdholloway: I think those can come later [22:09:28] jdlrobson: Should we slow down the switchover to the new summaries due to https://phabricator.wikimedia.org/T182321#3990934? (cc:Pchelolo) [22:11:43] bearND: ping be when you decide, I can stop the enwiki dump if needed [22:21:05] Pchelolo: I think it's really up to the web team. Also cc niedzielski . [22:21:39] bearND: ye sure, just you've been acting as a mediator in this effort so I'm asking you :) [22:22:13] Pchelolo: how far is it on enwiki? [22:22:56] bearND: not very, it's being pretty slow, somewhere around Armenia now [22:24:35] Pchelolo: ok, I think let [22:25:02] s stop the dump for now. I can also see some weird thing on an enwiki page. [22:26:58] done bearND [22:38:14] Pchelolo: jdlrobson: niedzielski: created subtask T187955 [22:38:14] T187955: Page preview shows icon instead of thumbnail - https://phabricator.wikimedia.org/T187955 [22:40:43] (reading backlog) [22:45:17] i can repro the issue as bearND has shown in the task [22:48:21] niedzielski: looks like the thumbnails get messed up in PagePreview land, see my update on the task [22:49:27] niedzielski: looks like the thumbnail URLs get modified somewhere (after the summary response) [22:49:45] gr [23:25:12] bearND: if you put a breakpoint on generateThumbnailData in rest.js, you can see the correct thumbnail url feed and the incorrect url come out [23:28:02] the function has no dependencies locally, so it's easy to run in a node repl and i can repro using the Red_Giant_Earth_warm example too [23:28:07] niedzielski: yeah, i saw that and added that to the ticket [23:29:19] oh i see, nice! [23:29:30] niedzielski: I ran this in the Dev Console: [23:29:33] https://www.irccloud.com/pastebin/V7SNgyTI/ [23:31:03] niedzielski: I think mdholloway has a good point about that we should be reconsidering requesting 1024px thumbnails. [23:31:13] mdholloway: do you remember why we went so large? [23:31:39] bearND: so is the correct fix here not to do the parsing at all since it's in the response fields now? [23:31:43] bearND: i think it's because that's the base URL we use to write downward for constructing 640, 320, etc in mobile sections lead [23:31:59] we use the same mwapi page metadata call for all endpoints [23:32:06] i've been thinking we should split them up a bit anyway [23:32:26] mwapi.getMetadata is getting pretty heavy [23:32:37] since we use it for everything [23:32:54] niedzielski: well, it's not that easy unfortunately. I think what you're getting right now is not what you want since the thumbnail would be too big for preview purposes [23:33:09] or i should say unnecessarily big [23:33:25] ah, too bad :/ [23:34:25] I think we need to change both the summary output and the client code (to avoid running into this on smaller sized images). [23:35:36] seems like all that needs to be done client side is to bail out of rewriting if (!thumbnail.contains('px-')) [23:35:53] i wonder, though, if there's an existing way to coerce the API to give us a real thumb URL [23:36:30] er, s/thumbnail/filename [23:36:37] Not sure if the API wants to be coerced to do that due to cache splitting concerns [23:37:16] mdholloway: do you think we could change the value to 320px? [23:38:18] bearND: sure, want me to write up a quick patch? [23:38:39] mdholloway: works for me ;) [23:38:42] 1024px doesn't make much sense as a thumb size in its own right [23:38:54] ok cool [23:39:19] mdholloway: Pchelolo: we should probably bump the summary version [23:39:23] to 1.3.1 [23:39:41] * Pchelolo readinng the backlog to get the context [23:40:48] Pchelolo: is the summary version hard-coded on the RB side: https://github.com/wikimedia/restbase/blob/master/v1/summary_new.yaml#L31? [23:41:33] bearND: that's the 'expected' version that's used by the filter [23:41:57] when we bump this one and enable the filter it compares what it got with the expected version and updates if nessesary [23:45:15] Pchelolo: let's say we change the MCS implementation to declare a summary version of 1.3.1. Should this be changed in RB, too? [23:45:44] bearND: not nesessarily, only if you want to enable a filter and force an update on everything [23:46:52] Pchelolo: I think we'd probably want to force an updated on the ones already on 1.3.0 to 1.3.1. The ones still on 1.2 could come at a lower prio. Not sure if that's possible. [23:47:23] bearND: no, that's not possible.. [23:47:37] when you get 1.3.1 out I can run a dump on cswiki again, that probably the best we can do [23:48:10] Pchelolo: ok, then we'd just do a dump on cswiki and then followed by the other wikis you did earlier (once we have a fix for MCS deployed) [23:48:41] "other wikis" is enwiki that didn't really progress much (got to Armenia) [23:48:54] lol, i guess we are in agreement since you wrote the same thing [23:49:35] when do you plan to roll out the fix? it's 9 pm here, but I will be online for a while [23:51:51] Pchelolo: very soon. mdholloway already has a patch up [23:51:59] ok, ping me [23:52:40] mdholloway: do you want to deploy, too? [23:52:46] bearND: sure [23:53:03] mdholloway: thanks [23:53:04] starting the deploy dance now, will build the repo as soon as it merges [23:53:33] P.chelolo: sorry, i didn't know you're not in SF. [23:55:42] bearND: oops, version bump [23:59:16] bearND: mdholloway is the URL actually incorrect for the thumbnails? for example, i get back https://upload.wikimedia.org/wikipedia/commons/a/aa/Red_Giant_Earth_warm.jpg which i can't construct into 512px-Red_Giant_Earth_warm.jpg even if the parsing is working correctly. the correct url is under /thumb/ like [23:59:16] https://upload.wikimedia.org/wikipedia/commons/thumb/a/aa/Red_Giant_Earth_warm.jpg/512px-Red_Giant_Earth_warm.jpg [23:59:19] mdholloway: oh, right