This approach makes more sense to me but again, by making the Stream name field active by default means that the Custom option is selected by default in the Schema type field.
Is this really what we want?

I have found the solution for this issue in the following sample in the codex documentation: https://doc.wikimedia.org/codex/latest/components/demos/menu-button.html#triggering-events-on-selection
It turns out we can reset the current state just running selection.value = null after handling the action for any menu item (as the example above shows).

Oops! In reality I wanted to post that in the ticket we have related to this issue in our board and I ended up posting on yours xD. I didn't realize there are two separate (and pretty identical) tickets about this. Anyway, good to know it was useful for you to close yours.

I have checked that this same behaviour is present when browsing Codex documentation clicking on some sample related to the MenuButton component. That would mean that is not something we are doing wrongly. I have posted something on talk-to-design-system-team Slack channel to ask for help just in case there is a workaround or something we can do to fix it: https://wikimedia.slack.com/archives/C03DKGSEPL2/p1734110680848909

I have found the solution for this issue in the following sample in the codex documentation: https://doc.wikimedia.org/codex/latest/components/demos/menu-button.html#triggering-events-on-selection
It turns out we can reset the current state just running selection.value = null after handling the action for any menu item (as the example above shows).

It seems this task was solved somehow somewhere previously. Probably while working on something related to styling MPIC. All pages are aligned to the top even if the content is shortened without covering the whole vertical space available)

The related MR is ready for review: https://gitlab.wikimedia.org/repos/data-engineering/mpic/-/merge_requests/150

The simple fix implementation and a related unit test case to test it is ready in the following MR: https://gitlab.wikimedia.org/repos/data-engineering/metrics-platform/-/merge_requests/78

alternatively, in the spirit of keeping things simple, we could update the Metrics Platform Client to check if there's experiment enrollment information in the event and merge it with the return value of Integration#getCurrentUserExpeirments() if so?

Related MR is ready for review: https://gitlab.wikimedia.org/repos/data-engineering/mpic/-/merge_requests/139

A related MR is ready for review: https://gitlab.wikimedia.org/repos/data-engineering/mpic/-/merge_requests/137

A related MR is ready for review: https://gitlab.wikimedia.org/repos/data-engineering/mpic/-/merge_requests/137

A related MR is ready for review: https://gitlab.wikimedia.org/repos/data-engineering/mpic/-/merge_requests/137