Should be fixed now!

Should be fixed now!

this ticket should probably have been tagged in this patch https://gerrit.wikimedia.org/r/c/mediawiki/core/+/762945/
The "Special:" namespace works if you add the colon i believe.

@Eevans how do you imagine the reuse? something like a new repo whose docker-compose (or Dockerfile or blubber file) does a git clone for all the different repos when spun up?

Considering the amount of logic involved, I would recommend disposing the redirect target if it is unusual in any way and instead return the same as the status quo

@Milimetric @BTullis Wondering if you had any opinion or oppositions to the proposed new Problem object?

This seems to happen when the value (or its destination) is a special page.

Yes. This error was when the redirect was to a Special page, to be fixed by the patch at T301346 as @Krinkle stated.

New problem type proposal below.
Changes include:

• detail is now a string, not an array (per the RFC)
• Add title field, and put what was previously in detail in title field
• Remove type, as it was more or less synonymous with the HTTP status code message

@Majavah i followed up with @Krinkle on IRC and we cleared up my confusion, thanks!

I'm seeing this same error locally when testing specific behavior of some REST API endpoint changes for T303352, but having a hard time debugging the path from ParameterAssertionException being thrown here to this error being thrown. I think @aaron's comment above might explain the problem i'm seeing, any chance of helping me step through this particular use case @aaron ? :)

duh, those too. thanks @apaskulin : )

This ticket was discussed and semi-debugged in an ad-hoc thread on slack.
The outcome is to complete T301346 which would include Special pages in search results (as this bug is coming from searching for a redirect page that is a Special page)

This error used to occur semi-regularly but hasn't occurred since Jan 24th. @BPirkle are you ok if we close and (re-open) if it starts up again?

Updated mediawiki REST API docs. That seems to be the only docs to update.

I think what is happening is that the results are coming back in different orders from Sqlite vs MySQL which is affecting how the code deals with duplicates:

@LucasWerkmeister that feels like a good idea at this point, since pinning OAuth's psr version is causing some other incompatibilities. Im not sure how often T287972 is worked on, but @Jdforrester-WMF said its on an ad hoc basis, maybe this could warrant a release sooner? :)

Sounds like a logical enough hypothesis to me ! haha. glad its as expected now

@alexhollender_WMF
hm this is really odd. I'm getting different results for the all of the "unexpected" screenshots.

I was able to reproduce this behaviour in a somewhat consistent way:

• If you try to submit the form (but the form is invalid, and prompts you to change some field entries) the Grant Types input becomes enabled again, and therefore the Grant Types are successfully submitted to the database (although you have to re-select them from the dropdown)

@Krinkle it looks to me like this endpoint has always been filtering out Special Pages from search results (see this older branch) but I'm wondering how you generated the screenshot, i might be misunderstanding the code that i linked

@Tgr wait you're right. i can replicate this every single time locally, but i just looked in Meta and looks like there are only 5 OAuth2 apps with empty grant type lists. Do you think its possible there are different settings applied to production that arent applied locally, affecting the ui ?

How can I test this? It doesn't seem like beta has the complete set of search results to work with so it's difficult to tell what would happen in production

@Krinkle there's a lot of residual effects that i was totally unaware of, thank you for bringing these up.

completed in: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/services/example-node-api/+/b99a82159f2fe6ac42b7543c47819326dd7b4e6f

Thank you @Zabe for the patch - definitely a big miss on my end.

Unclear the initial purpose of this task. Declining for now.

I just checked again and looks like the checkbox was hidden after this ticket was created in this patch by @Tgr this past August.

@bd808 i tinkered with this a little, and I think the actual issue might be actually related to T297888. When I create an OAuth 2.0 client, the grant types are not being saved to the database (as is described in T297888) and I receive the same error you noted. However, when I hack around the UI to get the grant types to actually save to the database and then I supply a redirect uri that does not match that which i initially registered with, I do in fact get a specific error message with the attribute: hint: Invalid redirect URI.

Link to the Pre-Mortem post-survey results

@Andrew Ok cool - yes I was able to go through the psql command line to create the user instead! However I ran into another problem when doing so. When I tried to connect via cli, I realized I needed to actually specify the database name, but I'm unable to create a database in the horizon UI (I get a similar error as the one when trying to create a User). It took me longer than I would have liked haha to realized the default database is postgres and eventually was able to connect to create a database and a new user.

thanks @bd808 !

@bd808 apologies - forgot to finish that last part.
bastion-eqiad1-01.bastion.eqiad.wmflabs:/home/nikkin/2fa-reset-request.txt

oh wow i completely missed that section of the documentation! thank you! closing :)

[Copied from slack thread on this topic]

@BPirkle and I discussed where in the development process it would make sense to do the linting/formatting. Ideally we would do the linting as early on in the process as possible.

@dduvall ok so, had a little "feel a little dumb" moment becaue your initial thoughts to push back on this were on point:

@sdkim @BPirkle @codebug according to the toolkit,

@dduvall awesome I think this will work great, thank you Dan!

@Tgr After i posted that comment i did end up indexing all the language tables, so those 4 should also be just as fast as well, so no need to omit the source filter!

@Tgr Can you confirm its more performant now? I think it should be! (for enwiki queries)

@Tgr Re: metrics, in my conversations with the cloud team I deduced that there was no way to publish metrics as of now because the API is hosted in a non-prod environment (cloud vps) and not under the deployment-prep project (which I believe is the only non-prod project able to publish metrics).

@dduvall Since we need to authenticate with Jenkins for read access to the build artifacts (https://integration.wikimedia.org/ci/job/mathoid-pipeline-test/lastSuccessfulBuild/execution/node/3/ws/openapi.spec.yaml/*view*/) im looking into how best to do authentication with an external app (our instance of Backstage). would it be something like this? https://www.jenkins.io/doc/book/system-administration/authenticating-scripted-clients/ using a service account + token ?

@dduvall awesome thanks for putting the example together! A couple clarifications:

@dduvall

By "a script to re-generate the openapi spec" do you mean for each service repo, or is this a central repo somewhere? Can you link me to an example?

@dduvall I appreciate the ask for background info! We want what seems most similar to the first "pre-merge generation" bullet, with a slight difference. We want a script to re-generate the openapi spec before the patch is merged (just as the bullet states). The script would take JSDoc function annotations > bundle and transform those into a single open api spec file.

that was so quick, thank you @dduvall !

@Tgr deployed!

oh ok! In that case I'm wondering if we could create another job that would publish these ephemeral artifacts to a repository, instead of leaving them there to get garbage collected. Is that possible at all, or do you think thats even a good idea...haha