Probably need to set the correct Docker image somewhere, see https://integration.wikimedia.org/ci/job/mobileapps-periodic-test/167/console:

npm: command not found

@JMinor Friday should be ok, as long as the extension is ready and the URLs are published.

Is the start of the announcement not too early? the links are not filled out in https://www.mediawiki.org/wiki/Wikimedia_Apps/Reading_list_browser_extension yet.

Yes, now the vagrant commands work again for me. :) Thank you!

The cherry pick works but is essentially a no-op since the patch is already in the history of my git clone.
So, the result of the vagrant command is the same.

I can reproduce this in FF and Chrome, laptop and phone. The icon ends up overlapping the text.

Here's the output @Tgr asked me for, but I only get the error when his patch is checked out, not on master:

The announcement period is over by now.

Now http://localhost:6927/en.wikipedia.org/v1/page/summary/W%3A%3AMammalia returns a 404 instead.

These three are all fairly new wikis, see T192678. I think RI needs to add these to the project whitelist for the Readinglist MW extension. Maybe @Tgr can walk the rest of RI through how this is done during the Hackathon?

@mobrovac Links to the docs and/or concrete examples of the actual format would be good to have.

@Pchelolo Oh, I was thinking more of a JSON endpoint. Not sure if the apps want to also add libraries for parsing yaml.
So, were you thinking that the domains that don't support a featured feed card would be omitted in this output?

@Pchelolo would you add some example output or show how the output format would look like for this?

As far as I understand this issue is only with the apps, not Mobile Web or Mobile Content Service. While I do not get the toast message with the error message I saw in the screenshot above I have a potential fix, see my gerrit patch above. The issue is that some wikis, like zh-yue, have hyphens in the subdomain but the database name has _ instead. See config. So, zh-yue.wikipedia.org -> zh_yuewiki.

Sounds interesting.

+ Services for visibility. We'll need to expose this endpoint through RESTBase. The output is fairly static (same output for every WP project even). The only time this can change is during MCS deploy time.

Does this actually happen on real pages?

Yes, @mobrovac, appservice.wmflabs.org and BC are separate instances.

In T194276#4194908, @Pchelolo wrote:

re appservice, do we have a real beta cluster instance already? RB is still going to the appservice for tests

One thing to try is to retrieve the revision number from the edit response, and use that when loading the just edited page.
.../page/mobile-sections-lead/{title}/{revision}
+ .../page/mobile-sections-remaining/{title}/{revision}

@Dbrant I'm using the same min/max versions for the app ass previously?

const androidMinVersion = 230;
const androidMaxVersion = 240;

@Dbrant to get this to run in prod only i set beta to false, right?

@RHo Would next week work for you?

The new field is called description_source. If it is present then you can see if the description was provided by the local (Wikipedia) wiki or by the central (Wikidata) wiki.
I think you want to disable editing if it's not from the central wiki or the value was not found (since the page had not been updated since T191869 was deployed.

purged https://en.wikipedia.org/wiki/Wagon_Train
and tested
https://en.wikipedia.org/api/rest_v1/page/mobile-sections-lead/Wagon_Train
https://en.wikipedia.org/api/rest_v1/page/summary/Wagon_Train

Even with the latest replayer version (2.2.3) I see the same issue:

     another server, GET without body: 504:
   504: internal_http_error
Error: incorrect header check
    at Zlib._handle.onerror (zlib.js:371:17)

Not right now. Hopefully in the future.

Turns out this was due a local code modification. Once I reverted that it worked.

In T191785#4158026, @Mholloway wrote:

I don't much like the idea of putting it in the existing feed endpoint, because that's a very un-performant endpoint with a processing-heavy response and I'd hate to increase traffic to it unnecessarily just to get this little snippet. Of course we'd hope that clients would be good citizens and cache this info, but I wouldn't want to rely on that.

https://github.com/wikimedia/restbase/pull/980 for Services to deploy

We should either keep this open for Android unless the Android team has a task for the app work for this.

I think we can close this with the caveat that www.wikidata.org has to be used instead of just wikidata.org.
Not sure when the fix was made but curl -sI "http://0.0.0.0:6927/www.wikidata.org/v1/page/summary/Q1" returns status 200 with type: no-extract now.

I'm concerned that these did not show up in Kibana.

That sounds good to me.

If we end up doing this then it would be good to add an additional prefix to the messages that are only in the browser extension, so they can be easily moved to the right place. Sounds like there is not much overlap between the two in terms of message, so maybe keeping it separate from the start makes sense.

@Fjalapeno Unfortunately, it's still very high, in the 500s per day according to Kibana.
I don't have a great idea to fix it directly, but once we split up MCS into multiple dedicated services, we might figure out which ones is to blame. One suspicion is the summary since that one was new when the worked deaths increased significantly.

@Mholloway The dash in the non-editable makes it a bit harder to deal with. Are there any alternate names you like?

Ok, then the workaround is fine with me.

Are most of the browser extension messages already present in the MW extension?

abcense of : is a clear indication that the page is in the main namespace

The only reason for their existence I can come up with right now is to have the entry in the ToC and be able to jump to that section. In general I think the app just should add the edit button if the section number is non-negative.

@Mholloway I do see your ack in the Icinga UI:

feed/annoucements expected output discrepancy will be fixed during today's deployment (see a992d05)

I agree with most what was written above except this part:

Hmm, that's strange. In the past I've seen Parsoid throw a 413 T184498: 413: Request Entity Too Large in Parsoid in cases where the wikitext is too big. Maybe this has changed or this case is different because the table is the thing that's so big? Should we split this one off and add the Parsoid tag?