The Phab logs at https://phabricator.wikimedia.org/conduit/log/query/CeBQRfyke.OE/#R show that @Pywikibugs calls the following "frozen" (kind of means "deprecated") Phabricator Conduit API calls:
The calls in https://gitlab.wikimedia.org/toolforge-repos/wikibugs2 should be updated accordingly.
| Title | Reference | Author | Source Branch | Dest Branch | |
|---|---|---|---|---|---|
| phorge: Replace frozen maniphest.info with maniphest.search | toolforge-repos/wikibugs2!72 | h2o | work/h2o/maniphest-search-migration | main | |
| phorge: Use user.search Conduit endpoint | toolforge-repos/wikibugs2!63 | bd808 | work/bd808/conduit-api-updates | main |
The user.query -> user.search switch is pretty easy. The other two are going to take a lot of staring at code and API responses to figure out.
bd808 opened https://gitlab.wikimedia.org/toolforge-repos/wikibugs2/-/merge_requests/63
phorge: Use user.search Conduit endpoint
bd808 merged https://gitlab.wikimedia.org/toolforge-repos/wikibugs2/-/merge_requests/63
phorge: Use user.search Conduit endpoint
Mentioned in SAL (#wikimedia-cloud) [2025-11-26T23:05:18Z] <wmbot~bd808@tools-bastion-14> Restarted phorge job to pick up new container (T402454)
I got the easy one {{done}}, but the other two are going to be quite a bit more work. The application is using the data structures returned by maniphest.gettasktransactions and maniphest.info directly without any intermediate value object representation. The suggested replacement APIs have very different response structures that will need to either be repacked into data structures matching the prior responses or the business logic working with that response data will need to be checked carefully and updated to match the new payloads. Either way this is more work than I have the spoons for at the moment.
h2o opened https://gitlab.wikimedia.org/toolforge-repos/wikibugs2/-/merge_requests/72
phorge: Replace frozen maniphest.info with maniphest.search
The above MR covers maniphest.info -> maniphest.search.
For maniphest.gettasktransactions, I noticed that transaction.search does not expose mergedinto data (type=null, empty fields). This would break the duplicate task reporting. Not sure if there is another stable way to get this info
Thanks a lot for the maniphest.info patch, very appreciated! Now I wonder who could review that.
Also, that feedback on missing output in transaction.search is helpful, let me forward that to upstream: https://we.phorge.it/T16634 / https://we.phorge.it/D27064
I'm sure you did not mean this to feel like a passive aggressive complaint about my mean time to review drive-by patches, but it still hit that way.
@bd808: Meh, sorry. No it was not meant like that; I was honestly wondering who may find time at some point, given that we have a lot of deployed software without clear maintainers.
Wikibugs has a lot of maintainers in theory: https://toolsadmin.wikimedia.org/tools/id/wikibugs
In practice, it's me. This tool was historically maintained by technical volunteers, but Merlin, Kunal, and Yuvi have wandered away over time. I did a major update of the tool in 2024 during a period when the tool was struggling. I also had time to try and make it more robust generally then. Since that time it has gone back to best effort support for me personally. I have added wikibugs along with about twenty other tools that I created/maintain to the tracking sheet for the in-development WMF service catalog. I would love to believe that will eventually lead to a WMF engineering team taking the tool on as an active project. Eventually is likely the key word there however.
Thanks both for the context. No rush on the review from my side, I can rebase whenever needed. Also, I can help with wikibugs testing or anything else if that is useful.