[11:23:58] <dcausse>	 lunch
[11:46:02] <pfischer>	 Lunch + errand
[12:55:48] <ebernhardson>	 \o
[13:01:20] <dcausse>	 o/
[13:15:35] <inflatador>	 <o/
[13:15:40] <dcausse>	 searchsatisfaction.event.articleId is the id of the page the user is currently on not the pageid of click apparently?
[13:15:53] <ebernhardson>	 dcausse: correct, it's the page the event was sourced from
[13:17:16] <dcausse>	 ebernhardson: do you have notebook that can correlate the clicked page id with possibly one of the corresponding srp event in autocomplete?
[13:22:32] <ebernhardson>	 hmm
[13:24:19] <dcausse>	 the more I look at it more I feel it's going to be complicated
[13:24:22] <ebernhardson>	 not finding anything, we haven't done all that much with autocomplete
[13:25:10] <dcausse>	 other than a bold guess joining on identity fields and webrequest
[13:26:51] <ebernhardson>	 tyea perhaps can awkwardly look at the hits from csrq, and the visitPage position/page, but thats going to be tedious
[13:29:38] <dcausse>	 yes... but I don't trust the ordering in csrq (esp. for autocomplete) and with so many search_token missing I was trying to find other ways to join the two
[13:30:01] <dcausse>	 and the clicked page_id could possibly have been one
[13:32:33] <ebernhardson>	 yea makes sense
[13:36:01] <dcausse>	 I think I need to fix few things: populating csrq properly with the top-level hits during comp_suggest and understand why X-Search-ID is not propagated properly
[13:38:59] <dcausse>	 x-search-id is not passed from the /rest API used by the new autocomplete widget, explains why ruwiki which is still using the old one has it more
[13:39:08] <ebernhardson>	 ahh, yea that makes sense
[13:42:14] <dcausse>	 also this header seems to get cached
[13:42:34] <ebernhardson>	 oh! i mean obviously yes but not sure i was thinking about that at the time
[13:43:05] <ebernhardson>	 i suppose it's still technically true, the log matches the response, but could be from awhile ago 
[13:46:54] <dcausse>	 yes, no clue what's the actual impact but seems like we don't use this token much outside of fulltext
[14:52:13] <pfischer>	 Today's a P + T meeting. Do you want to attend live or shall we have a Wednesday meeting? I only have a few questions, but they could wait
[14:53:47] <ebernhardson>	 i can watch the video for P+T, should be fine
[14:56:14] <dcausse>	 have a small topic for the wed meeting as well
[15:27:27] <inflatador>	 dcausse ebernhardson I'm just looking at my Gerrit board, is this change still needed? https://gerrit.wikimedia.org/r/c/operations/puppet/+/1210636
[15:43:17] <Neriah>	 no
[15:43:19] <Neriah>	 https://gerrit.wikimedia.org/r/c/operations/puppet/+/1224063
[15:59:26] <inflatador>	 ACK, thanks
[16:26:55] <ebernhardson>	 inflatador: can we apply the 64kb readahead to eqiad and codfw semsearch clusters?
[16:27:22] <ebernhardson>	 only eqiad is queried in prod though
[16:49:48] <inflatador>	 ebernhardson ACK, hitting it now
[16:49:56] <ebernhardson>	 thanks!
[16:56:22] <inflatador>	 had a few failures due to newly-reimaged hosts, re-running
[16:57:49] <inflatador>	 ebernhardson you should be good now. Looks like the 2 failed hosts aren't finished reimaging yet
[17:00:01] <ebernhardson>	 kk
[17:10:37] <inflatador>	 In other news, my crappy python script to set ureadahead seems to be working https://paste.opendev.org/show/831520/
[17:17:31] <ebernhardson>	 \o/
[17:31:06] <inflatador>	 working out of https://gerrit.wikimedia.org/r/c/operations/puppet/+/1254320 , we'll probably want to hide it behind a feature flag and only roll out in CODFW to start
[17:38:30] <inflatador>	 I cc'd you on the change, but feel free to review/offer suggestions
[18:34:38] <ebernhardson>	 cleaned up the morelike report a little bit, might be usefull someday: https://people.wikimedia.org/~ebernhardson/morelike.html
[21:22:06] <inflatador>	 ebernhardson have you ever seen `org.opensearch.action.search.SearchPhaseExecutionException: all shards failed` or thereabouts in ES/OS logs? It's appearing in ipoid logs. Probably not good, but not sure how bad ;)
[21:28:30] <dcausse>	 inflatador: depends on the actual cause but looked at logs and saw "The parent task was cancelled, shouldn't start any child tasks, channel closed", I suspect it could be a symptom of the app side timeout?
[21:30:54] <inflatador>	 dcausse thanks for looking! It also seems like it's a warning so maybe not as bad as it sounds
[21:36:57] <dcausse>	 event I found them annoying the top-queries indices have perhaps something useful in them? curl -s https://opensearch-ipoid.svc.eqiad.wmnet:30443/top_queries-2026.03.18-25350/_search?sort=measurements.latency.number:desc | jq .
[21:47:36] <inflatador>	 ah yes, that damn performance analyzer stuff ;)