Some interesting stuff from this presentation:

• defunctzombie/browser-stacks - collected examples of stack traces in various browsers, might be useful for testing
• Error.captureStackTrace / Error.prepareStackTrace - experimental V8 API which allows direct access to the stack trace object (with function objects and everything)
• zone.js - scary but powerful tool to define execution contexts which track async calls

It looks like a large number of the blockers here have been left without any projects.

Added them to Sentry.

Hey @Tgr, I'm going to work on this as a side project, to get more familiar with mediawiki. I'm going to read up on the status in the various subtasks, let me know if there's somewhere obvious I should start.

@Milimetric cool! Note though that all this is very outdated and currently most of the work is not in MediaWiki. I wrote a more current summary in T217142#5103038.

Thanks @Tgr, that's a big pivot from what I was expecting, but hey, let's do it! How/when/who is making the decision on each bullet point? I could drive client and pipeline work, and beg ops for help with the Sentry server / Logstash part. In terms of owning the work going forward, I think Analytics is overloaded at the moment but it makes the most sense there. Extension:Sentry is broadly similar to Extension:EventLogging, and it sounds like EventGate/Kafka is the preferred choice for the pipeline, so that's squarely in our world.

I propose that I work on Extension:Sentry and use @Jdforrester-WMF's help to decide between sentry/browser and a custom implementation. Maybe we could look at sentry/browser and trim it down into some sort of sentry/browser-lite that we could convince upstream to maintain. Surely other people are interested in a client lighter than 50k.

If there are no objections by Monday, I'll reach out to James.

@phuedx can you comment? You probably have a better grasp of the current status.

In T382#5108028, @Milimetric wrote:

Thanks @Tgr, that's a big pivot from what I was expecting, but hey, let's do it!

<3 <3 <3

How/when/who is making the decision on each bullet point?

As yet, this is unclear. @Tgr has done an incredible job breaking down this work and implemented at least one MVP for Multimedia IIRC; I've poked and prodded a bit in T217142; and @fgiunchedi (and SRE) have very recently picked up the proverbial torch.

I could drive client and pipeline work, and beg ops for help with the Sentry server / Logstash part.

SRE seem willing to drive Kafka/Logstash part of the pipeline. IIRC they're looking at Q1-2 FY19-20.

In terms of owning the work going forward, I think Analytics is overloaded at the moment but it makes the most sense there. Extension:Sentry is broadly similar to Extension:EventLogging, and it sounds like EventGate/Kafka is the preferred choice for the pipeline, so that's squarely in our world.

I'm a little nervous about ownership of an infrastructure piece as critical as client-side error logging being shared by more than one team as it could lead to friction when prioritising bugfixes/maintenance/feature requests. In practice, though, this likely won't be so clean cut, e.g. the client-side component could be maintained by Readers Infrastructure in Audiences. Let's talk about this sooner rather than later.

Shipping an MVP by any means makes sense though!

I propose that I work on Extension:Sentry and use @Jdforrester-WMF's help to decide between sentry/browser and a custom implementation. Maybe we could look at sentry/browser and trim it down into some sort of sentry/browser-lite that we could convince upstream to maintain. Surely other people are interested in a client lighter than 50k.

I wonder how many browsers @sentry/browser supports that we don't deliver JavaScript to. One path might be to not go completely custom but to trim out any parts that won't apply to the Wikipedias, if any.

@Milimetric are you still interested in moving this forward?

@daniel sorry I didn't update the group on this, but this project is being led by Filippo and progressing nicely. There's a working version deployed in beta and progress on a production launch is tracked here: T226986. I'm not sure at this point how that interacts with this RfC. Maybe we should update it when we have a good idea what the production stack should look like.

@Milimetric That sounds like this RFC has been overtaken by reality and can be closed as invalid. Or do you think it's still useful?

I suppose the key question is: is an RFC still needed to make sure that there is agreement about the service interface and the backend technology? How where the requirements/constraints gathered, are they documented somewhere? If yes, would it make sense to just put this on last call?

I think that's right, we have a pretty good working group of the people that care about this. If they agree I don't see too much need for an RfC, there would be too much context for someone else to catch up with. So I would vote to close as invalid. As for requirements/constraints, I think the phab tasks describe those for now, and we'll document them as we go forward (there's still thinking/testing on what the stack should be)

FWIW I concur we can close this as invalid, there's good input/ideas in children tasks, some of which we could integrate in T217142: [Proposal] Use the Kafka-Logstash logging infrastructure to log client-side errors. @Tgr what do you think ?

In T382#5364914, @fgiunchedi wrote:

FWIW I concur we can close this as invalid, there's good input/ideas in children tasks, some of which we could integrate in T217142: [Proposal] Use the Kafka-Logstash logging infrastructure to log client-side errors. @Tgr what do you think ?

@Tgr: Could you please answer the last comment? Thanks :)

The fact this is open and that much of this has been implemented is causing me some confusion. Per T382#6241903 can this be merged into T226986 as that seems to be the canonical link for tracking this work?

The proposal outlined in this task was about building dedicated infrastructure around error monitoring, with an elaborate client and dedicated server-side and UI component (Sentry).

This has not been actively pursued for couple years now, with a lot of the effort having been shifted toward re-using our existing infrastructure first (statsv, kafka, Logstash/Kibana), with the most recent related RFC being the Modern Event Platform (MEP) - T201963.

This task hasn't been on the active RFC track for 5+ years so I'll close this for now, but feel free to re-open or create a new one at any time.

https://www.mediawiki.org/wiki/Requests_for_comment