In T416544#11587322, @Ladsgroup wrote:

Two notes:

• Maybe add unsigned to give yourself more breathing room.
• If you have the user as unique key, why not making it PK directly and avoid having an extra auto_increment id? See T411433#11584647 onwards

In T415902#11573319, @Niharika wrote:

Thanks for looking into this. I tried to get a hold of the totals on superset but realized they scrub gu_email(makes sense) so I can only get count and timestamp of confirmed emails but not the unconfirmed ones.

Note: as currently designed the oah_handle field is binary and contains binary values. However, we could store a base64-encoded value instead, if that is preferred.

I don't know how feasible it is to get this data into Logstash, because Logstash is more suited to event-type things, not tracking totals over time. We do already have useful information in the database that would allow us to get a snapshot of these metrics any time, and some limited information about what they might have looked like in the past (but finding a way to regularly snapshot them is probably better).

I would suggest also adding instrumentation for how many email confirmation emails are sent, so that we can measure what percentage these bounces are of the total.

Unfortunately this is "correct" behavior. Firefox on Linux does not support passkeys, because Firefox doesn't have a built-in password manager (like Chrome does), and there is also no OS-level password manager to integrate with (unlike on Mac OS or Windows). If you install a third-party password manager like 1Password, passkey support should work correctly.

Probably related:

I reran the query one more time, and it looks like the script is probably working. You can see clear spikes on Nov 17 and on Jan 17 (but not Dec 17 for some reason).

When you get to the passkey screen (after the username/password screen), you normally shouldn't even be able to click the "Continue login" button, because the browser's passkey UI should take over. What do you see on this screen? Does your browser or OS show anything offering passkey authentication?

In T411146#11500159, @sbassett wrote:

1. The various production dependencies within package.json. I ran snyk and osv-scanner against these dependecies - they found a medium severity issue for the dev dependency esbuild@<=0.24.2. This is a low-risk issue in this particular scenario since we shouldn't be running the vite dev server in any external capacity. And it's probably not easily addressed unless those get version-bumped (vitest 0.0.1 - 0.0.12 || 0.0.29 - 0.0.122 || 0.3.3 - 2.2.0-beta.2 => vite-node <=2.2.0-beta.2 => vite 0.11.0 - 6.1.6) by getting to vitest@4.0.16 which introduces breaking changes, apparently.

Rate limiting is already implemented, we just forgot to configure it.

Unfortunately this probably requires updating the nodejs20-slim image as well, because that includes Node v20.5.1 but Codex requires >=20.19.1.

Earlier this week I asked @Urbanecm to handle this, since deleting this group will require updating community process documentation and communication with the stewards and other users who often assign global group membership.

In T409508#11352208, @Agabi10 wrote:

The composer.json file of the main branch says the library requires PHP >= 8.1.0, so wouldn't named params with whatever default value the current components have be a better option than the array-style component construction? Those should work with Phan out of the box.

Sorry about this -- the reason this broke is because we changed the way we hide the close button from using v-if to using CSS. The previous way (v-if) didn't affect you because you override the header with a custom one so we don't render our own close button regardless. The new way (CSS) did affect you, because your close button in your custom header uses the same CSS class as our built-in one.

Hmm now that I'm thinking about it a little more... do we run mergeMessageFileList for each wmf.N branch separately? If we run it only once and reuse the result across both branches, that would be a problem if an extension was missing in one branch but present in the other.

In T411516#11424578, @bd808 wrote:

I have recently been talking with @Catrope and @thcipriani about the underlying problem here and would like their feedback on my problem description and proposed solution. Obviously input from others is welcome as well.

Another bug: the sticky header isn't wide enough to cover the entire width of the screen, so very occasionally some things on the page can appear beside it when you scroll. This happens for example on pages with a large number of references:

Eric showed me this feature today and I found a bug: when I view https://en.wikipedia.beta.wmcloud.org/wiki/Paris?useskin=minerva&useformat=mobile&stickyHeaders=1&useparsoid=1 in Chrome with mobile device emulation (I used the "Pixel 7" dimensions, 412x915px) and I scroll from the "Etymology" to the "History" section, there's an oscillation bug where the ext-readerExperiments-stickyHeaders on the "Etymology" heading is rapidly removed and re-added and removed again. This doesn't happen for any of the other section transitions on this page, and it also doesn't happen on the non-Parsoid version of the page for some reason.

Right now this is not expected to work, because using Codex components in wikitext directly like this is not supported, and we don't currently have a way to automatically load the InfoChip styles when there is wikitext on the page that uses an InfoChip this way. The reason it sometimes works and sometimes doesn't is that sometimes there's an InfoChip in use somewhere else in the UI, so the InfoChip styles were loaded for that feature.

I see the same purple as Jon does, in both light and dark mode, in Chrome. But I don't know where that color is coming from, I can't find a :target-text rule anywhere (and the inspector does not make it easy to find these). Perhaps the solution here is to explicitly customize the color of the :target-text (and maybe set it differently in light vs dark mode), but that should be done in the skins (MinervaNeue and Vector 2022), not (primarily) in Codex, so untagging Codex.

Everything works great, thanks!

I'd be OK with changing the background-color-*--hover and --active tokens to use transparency instead. I don't think we'd need to create new tokens, unless the switch to transparency would really break a different usage of these tokens.