And transferred to wikimedia group.

I've been looking into this and the task ain't easy - the fork significantly diverged from the master, so rebasing it on top of a current master is challenging.

This is increasingly becoming a problem as npm audit is reporting more issues from the dependencies.

Update: Now npm audit shows 2 vulnerabilities from limitation.

If this takes longer I suggest just updating its dependencies.

Can't any necessary rate limiting be handled by Varnish/Apache Traffic Server, at least in the WMF production context?

In T200374#5185738, @Mholloway wrote:

Can't any necessary rate limiting be handled by Varnish/Apache Traffic Server, at least in the WMF production context?

We (as in the WMF) are trying to minimise the reliance on Varnish for anything that is not related to caching (routing, rate-limiting, etc), so this would go against that effort.

In T200374#4974852, @KartikMistry wrote:

Update: Now npm audit shows 2 vulnerabilities from limitation.

Apologies for the hold-up. The dependencies have been updated, so now if you rm -rf node_modules && npm install, the vulnerabilities should no longer show. If you still use the deploy repo for your service (i.e. you are not on k8s), you should use --force when building the repo next time in order to pull in the updated dependencies.

I'm raising the priority of this yet again cause the fork has completely diverged from the upstream and it's getting to the point when it's dependencies are not supported either, so we really need to switch away from the fork.

I'm having another related problem. For some reason, lately, npm is sometimes not completely installing kad and its dependencies. In particular I'm finding that I frequently hit an error related to a missing colors module:

Error: Cannot find module 'colors/safe'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:582:15)
    at Function.Module._load (internal/modules/cjs/loader.js:508:25)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:22:18)
    at Object.<anonymous> (/home/mholloway/code/wikimedia/mobileapps/node_modules/limitation/node_modules/kad/lib/logger.js:3:14)

@WDoranWMF can you clarify why this was deprioritized to "low" given the problems it's causing elsewhere and previous comments at T200374#5538736 and T298854#7618747? service-runner is pretty critical to nearly all the services we run.

@Nikerabbit cxserver seems to be the only service apart from restbase using this according to codesearch. Since service-runner is unowned, I'll remove MediaWiki-Engineering but happy to discuss this if the change is important to you, please let me know.

In T200374#9485174, @MSantos wrote:

@Nikerabbit cxserver seems to be the only service apart from restbase using this according to codesearch. Since service-runner is unowned, I'll remove MediaWiki-Engineering but happy to discuss this if the change is important to you, please let me know.

Not against removing this from cxserver, it wasn't working anyway in a kubernetes environment (where cxserver was deployed) since it is implementing a very simple discovery mechanism that is not a good fit for an environment with ephemeral workloads. In the pathological case, it leads to 1 isolated DHT per pod. I have removed support from the chart myself in 8499d5aa41796bd8bbc754be1041ffc27d877917 in fact.

However, I am worried about the Since service-runner is unowned statement. Has this been raised/communicated/discussed etc?