Apr 26 2022
Apr 25 2022
Should be fixed now!
Should be fixed now!
Apr 14 2022
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.
Apr 13 2022
@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?
Apr 11 2022
Mar 31 2022
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
Mar 29 2022
Mar 28 2022
This seems to happen when the value (or its destination) is a special page.
Mar 23 2022
Mar 22 2022
New problem type proposal below.
- 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
Mar 17 2022
Mar 16 2022
@Majavah i followed up with @Krinkle on IRC and we cleared up my confusion, thanks!
Mar 14 2022
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 ? :)
Mar 11 2022
duh, those too. thanks @apaskulin : )
Mar 10 2022
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)
Mar 7 2022
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.
Mar 3 2022
Mar 1 2022
Feb 28 2022
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:
Feb 25 2022
@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? :)
Feb 24 2022
Sounds like a logical enough hypothesis to me ! haha. glad its as expected now
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)
Feb 22 2022
@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
Feb 19 2022
Feb 18 2022
Feb 15 2022
Feb 14 2022
Feb 11 2022
@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 ?
Feb 10 2022
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.
Feb 9 2022
Thank you @Zabe for the patch - definitely a big miss on my end.
Feb 8 2022
Feb 3 2022
Unclear the initial purpose of this task. Declining for now.
Jan 31 2022
Jan 27 2022
Jan 20 2022
Jan 18 2022
Jan 13 2022
Jan 11 2022
@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.
Jan 10 2022
Link to the Pre-Mortem post-survey results
Jan 7 2022
@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 !
Jan 5 2022
@bd808 apologies - forgot to finish that last part.
Dec 21 2021
Dec 18 2021
oh wow i completely missed that section of the documentation! thank you! closing :)
Dec 17 2021
Dec 16 2021
Dec 14 2021
Dec 13 2021
Dec 11 2021
Dec 10 2021
Dec 7 2021
Dec 6 2021
[Copied from slack thread on this topic]
Dec 3 2021
Nov 29 2021
@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.
Nov 28 2021
Nov 23 2021
Nov 22 2021
Nov 19 2021
Nov 18 2021
Nov 17 2021
Nov 10 2021
@dduvall ok so, had a little "feel a little dumb" moment becaue your initial thoughts to push back on this were on point:
Nov 9 2021
Nov 3 2021
@dduvall awesome I think this will work great, thank you Dan!