For reference, the current HTTP status codes returned from the WikiLambda run-function endpoints (internal and public) are documented here:

https://api.wikimedia.org/wiki/Wikifunctions_API/Reference/Run_Function

If the orchestrator introduces new non-200 status codes, we will consider whether the WikiLambda APIs should pass them through to the user, and if so they will also show up in our metrics events.

Very good points, @Jdforrester-WMF! I don't think I was aware of T358216 (and probably could've spent more time looking for similar tickets). I agree T358216 is generally more desirable. I was partly thinking about making it easier for a non-expert user to file a bug report (i.e., save the JSON stuff and attach that to a Phab ticket). I suppose they could use the capability from T358216 and then refer to that in their bug report - but there may be a concern of getting lots of superfluous tests created for bug report purposes. I agree the proposed button could cause confusion and possibly wasted time for non-expert users. Maybe one day if we ever do this it could be out-of-the-way in an Advanced menu option. Anyway, this ticket isn't urgent at all; the triage seems fine.

@phuedx - Thanks so much! I will check it out today.

Regarding the use of Metrics Platform instruments in our backend services, the relevant ticket (for the MP JavaScript library to be used in that way) is T318832, and it appears that much of the work has been done. As I learn more, I will add additional info here.

Thanks for creating this ticket, @phuedx . Also worth noting - For this little test, in LocalSettings.php, I have a stream declaration for submit_interaction_stream, as shown near the end of How_to/Setup_Mediawiki_for_Metrics_Platform.

Related to T354917, for which I'm planning to arrange for the orchestrator to return an error (Z527)

Over to Megan for final online QA

After discussing, we decided no changes in WikiLambda are needed. We rely on the orchestrator to check validity of input objects. WikiLambda cannot easily detect if the user has entered an input, or if the entered input is valid. Closing.

Hi @gengh

wlzo_list_position (If wlzo_key of main ZObject has a list value, the position of wlzo_ref_zid in that list)

What need does this column map to? Do we have an immediate need to query or measure the position of arguments? If not, I would drop this from the proposal and stick to the minimum number of columns necessary.

Hi @cmassaro – I can reproduce this in my local environment, using the Steps to reproduce above. I have saved the normal-form result both from the orchestrator, and also from WikiLambda code that receives the result, and it's the same. That's the large JSON file that's attached in the Description. I believe the reason it won't canonicalize is the presence of the following, unquoted, as the value of Z518K2:

A few queries this table could be used for:

@Jdforrester-WMF - Right; but OTOH the initial proposal is also simple, and has the advantages of greater generality and covering more needs as mentioned above.

Thanks, @Jdforrester-WMF ! Based on our discussion, I understand the appeal of the fingerprint column, and yes, the counterproposal would meet the need to track inventory and usage of types. However, there are some concerns:

Based on discussion within the Abstract Wikipedia team, we have the following proposal for one new table, proposed usage plan, and several questions:

Thanks, @MNeisler for the suggestions.