Low-level blame is easier than I expected: https://gitlab.com/wmde/technical-wishes/survey-tools/survey-dashboard/-/merge_requests/8

Will try to implement this by building a blame map starting with the first revision.

Thank you so much! This is resolved now with your clue, I've used our project prefix as the hostname.

I should have tried that—my other attempt was something like "www" which of course is also already a wmcloud.org subdomain.

In T379594#10314128, @Andrew wrote:

@awight I don't have a very satisfying explanation, but... can you try it now? I saw some errors which cleared up when I restarted the proxy backend API server.

Okay, it may be my problem! My application was only listening on ipv6:

Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp6       0      0 :::4000                 :::*                    LISTEN

Sounds like the tofu-infra todo is about something deeper than my user settings. But in case that question was for me, I had already modified the "default" secgroup to add an ingress rule for tcp:4000,

I'm having some trouble setting up the web proxy (T379594). Until it's fixed, developers can access using an SSH tunnel:

ssh -L 4000:localhost:4000 beta.wmde-techwishes-survey.eqiad1.wmcloud.org

http://localhost:4000

There were some hints that errors might be reported here, but I found nothing related:

kafkacat -C -b kafka-logging1005.eqiad.wmnet:9092 -t eqiad.w3c.reportingapi.network_error -o end

Probably not related, but I see a lot of errors about the maps-experiments project, which I was a member of at one point. Maaaybe this is exploding the web proxy script?

I can't find any errors in the Logstash dashboard for openstack eqiad ECS.

The remaining issue is not caused by MWDocumentReferences. We should continue with trying to fix, but the task description is no longer describing the root cause. I found the same issue present in REL1_42 and REL1_41, before the new mechanism was introduced.

There are some surprising entries in the ve-changes session storage. After making a change that involves a ref, the stored transaction will include a full copy of the internalList before and after the change, despite the difference only affecting a single item in the list.

I still see this, and perhaps the cause is different than in the above? My steps to reproduce are:

• Open https://en.wikipedia.org/w/index.php?title=Daron_Acemoglu in VE
• Select all and copy
• Open a local development wiki in visual editing mode.
• Paste content

As a semi-informed third party with a bad conscience (I may have written the code I'm about to complain about), I want to mention that CentralNotice itself is overdue for some performance attention. SpecialBannerLoader getJsNotice builds a string literal of the banner to render, when it should be possible to do this entirely with ResourceLoader these days. The string literal will need to be loaded repeatedly and we even prevent caching by sending headers with max-age: 0 !

We discussed this with @dchan and our current agreement is that we don't have to implement this mechanism yet. It would be acceptable to have the visual editing surface wired to a detached node, and then explicitly serialize the result back to wikitext which we store in an attribute.

We won't need object storage, so perhaps the dashes in the project name are acceptable? Otherwise, "wmdetechwishessurvey" aargh is fine.

The issue is not solved. Pasting the ref as described causes it to show up with number "[1]", although it's not a reuse of the first reference.

Demonstrate by showing the compiled and grouped list of custom marker sequences in the task description. The only surprising set is hywiki:N .