I caused this regression when working on T263247. A PR with the fix is ready for whenever this is triaged.

The team that owns the endpoint:

has tests for it running in the CI with every build
does not break existing functionalities by creating different versions of the endpoint instead of changing the existing one
Where does the QTE team help:

Having one dedicated person on the team OR helping the team with their test plan

These crashes are still occurring in 6.7.1, pulling into 6.7.2 for re-investigation

@Ladsgroup I was doing some CI experiments for iOS. I deleted the files stored by the actions and the repository itself, so we should be back under the quota as an org.

Thanks @Pchelolo !

This is borderline unbreak-now from the apps teams perspective as it's breaking a key component of the apps (the explore feed) for German users. The specific endpoint the apps use that is timing out is https://de.wikipedia.org/api/rest_v1/feed/featured/2020/09/24 cc @Charlotte @JMinor

Looks like the error string is page-protected-other

Reopening as it's still an issue in the iOS app. Will triage it through the iOS board for potential client-side workaround.

@holger.knust this bug is separate from T256491. It looks like the root cause had to do with assumptions about the cache-control header as per this comment. Marking this as resolved as I can no longer repro with the steps in the description.

@mpopov Thanks for checking the PR on a PR! Apologies if it felt mixed or unclear. The goal was to make the library easier for us to use and maintain going forward by replacing Objective-C structures and norms with their Swift equivalents. We stopped new development in Objective-C over two years ago, so it’s important that the library fits in with Swift norms. We’re willing to take the tradeoff of updating any legacy Objective-C logging code.

I think we haven't yet talked in a more holistic way about how the instrumentation might be organized, structured, etc., and I think Joe's patch speaks more to that.

Correct, the patch is mostly about making the instrumentation side a bit easier to use & maintain long term.

I'm unable to repro this on the latest iOS public beta - 14.0 (18A5369b) and Wikipedia app beta 6.7.0 (1753)

It might be worth investigating the alternative to performBatchUpdates to see if it fixes this issue. There's a spike that uses that new implementation on the ModernCollectionViewUpdater branch

@JMinor another option for this occurred to me - what if there was one string per-language Wikipedia in the language of that wiki? So for example, English Wikipedia would show "from English Wikipedia" no matter what the user's UX language preference. The localization language for this string would match the wiki language.

@ABorbaWMF thanks for reporting. You can workaround the issue in the build you have by searching for language code. So for example, Mon shows up if you search for mnw. The bug will be fixed in the next build and the languages will be searchable by name.

@ABorbaWMF thanks for reporting this. It should be fixed in the next beta.

@ABorbaWMF nope, should be all set after general testing on our end. Core Data is a framework Apple provides that had a part deprecated that we were using. Thanks!

@Mholloway this task is resolved. The notes from @Robocel above are guidelines to use when adding styles going forward, and if there's any action item to this, it would be to add that to a readme. I'll put up a patch for that.

We removed the unnecessary call to becomeFirstResponder() but it was ultimately fixed in newer iOS 14 betas.

Would either need to update the layout code for the button and lower label or disable swipe actions on this cell

shnwiki was added along with the changes for T239605

Agreed, a patch is up that adds all the missing languages and makes the process for adding new languages a lot easier.

A bit more than nqo was missing. Here's the full list:

@bearND thanks for the thorough writeup! No questions at the moment.

Yup

Blocked by simulator-only bug that makes the app mostly unusable - articles take a very long time to load. More info in the PR description.

Current active users (iOS/Android)
New users per month (iOS/Android)

Definitely worth doing if/when we revisit onboarding, but not worth keeping captured as a separate ticket

Unable to repro on 6.6.2, iPhone X

So we are all on the same page this will *reduce* the number of pageviews, see plot. For 2020/07/24 data for IOS the reduction is about 8% on data marked now as 'user'

Confirmed, that's expected given that we're now excluding requests to save for offline viewing and requests from versions older than 6.6.2.

Recreating it is an option. It'd probably be easier to recreate than downloading to a laptop and attempting to restore.

Hi @Andrew, 1 wouldn't be a problem. For 2 would the data be restored or would I need to recreate it from scratch?