After deploying it to production the chatty useless log messages no longer show up.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 1 2019
Merged and deployed. resolving.
In T182827#5384205, @MSantos wrote:@Pchelolo Would it be hard to include maps as well?
sure, a PR will be nice!
In T229521#5382928, @Mholloway wrote:Unfortunately, it doesn't look like our logging is capturing the request URLs in this case, so I don't know how to reproduce this.
Jul 31 2019
In rare cases when we need it we can run a query on hadoop.
doesn't seem to be any more movement or things to be done here.
I need to verify this is still the case and file subtasks for the appropriate teams.
No movement in 3 years clearly indicates this is not needed. Please reopen if I'm mistaken.
No real need for this has been.
I don't think we will/need to implement this.
Do we still need to work on this or it is resolved on the app side?
@Mvolz is it done or still considered or can be closed?
Given REST API in MediaWiki, this is not needed anymore.
We're updating to k8s and not running node 4 anymore.
We never actually got to the point where this was needed. we can reevaluate in the future.
old section retrieval API has been deprecated and removed.
We're moving to k8s, so the build script will be removed soon.
I believe this will never be done. Declining.
This is definitely overcomplication of the system.
Given that we only store latest revision now, it's not a problem any longer.
We don't really have/use change-prop in dev cluster anymore and I don't think we will.
@bearND Do you think it is still needed?
After switching to Proton this is not an issue any longer.
There has not been any complains about kafka queue not supporting these statistics, so I don't think it's worth investing time into it.
Given that matching TID for content pieces never became a requirement for the apps, we don't need to overcomplicate things here.
doesn't seem to be needed anymore.
There was neither movement on implementing it nor further requests from audiences. I don't think it's needed anymore.
Reading infrastructure has created references endpoint for the use of mobile.
Given introduction of the REST API in MediaWiki, I believe this is no longer nesessary in RESTBase
I believe this is invalid after so many years and changes in thinking.
I have evaluated the library, and it's a good piece of software, but currently, the URI templating functionality supported/required by HyperSwitch and RESTBase is too different from what the library provides. I don't believe using the library would worth the investment.
In T229286#5381396, @Mholloway wrote:Weird. Why are we still getting internal requests for /feed/onthisday/all, then?
In T229286#5381330, @Mholloway wrote:So one issue right off the bat is that we're generating /feed/onthisday/all in the service in addition to the individual pieces, which seems like a lot of redundant work. How much work would it be to compose /feed/onthisday/all in RESTBase instead, the way we've been doing with /feed/featured for some time now?
Aside from that, I would have expected that the pregeneration jobs would be finishing up by now and the worker deaths subsiding, but instead it looks like they're getting more frequent over the past couple of days. (Any idea when those will be finished, @Pchelolo?)
Jul 30 2019
The fix has been deployed. Now all PCS endpoints support language variants.
The fix will be deployed today, see the T229060 for the details.