[01:38:12] thanks Reedy! this helps a lot. now to figure out how to get android to scan it more often than once in 15 mins... [01:44:32] You can use RSS Feed Bot on Telegram also [04:38:09] Hi there, I was trying to install on my MW 1.42 but getting the following error so is there any documentation to handle such bugs? [04:38:09] MWExceptionHandler::handleUncaughtException() #24 {main} thrown in /public_html/extensions/TemplateStyles/vendor/wikimedia/scoped-callback/src/ScopedCallback.php on line 57 [04:50:40] Anyone around for a suggestion please? [05:05:59] Guest61: https://www.mediawiki.org/wiki/Manual:How_to_debug [12:52:39] Hi, is it expected to get lots of `Failed executing job: refreshLinksPrioritized` with `Revision 972859 is not current`? We use the kafka/changeprop/eventgate systems now. Just not sure if this is expected and can be ignored or is there anything I can do to fix it. [12:58:52] paladox: I think that is fairly normal. If its like 90% of the jobs that would be a bit weird, but it is expected that some jobs fail with that message [12:59:09] ah ok, thanks! [12:59:42] Its not really an error message so much as just a notice that the page has been edited in the mean time, so there should be a different new job processing it [13:00:30] ah, I wonder if the logging level could be downgraded to like a warning [14:27:25] paladox: what channel/severity is the message logged at currently? Does it result in the job being marked as failed and re-tried? [14:27:35] (if yes, that would be a bug) [14:28:09] It's logged in the error level and it does seem to mark as failed and re-tries it. [15:02:33] Krinkle: ^ [17:24:04] I filed https://phabricator.wikimedia.org/T379658 and https://phabricator.wikimedia.org/T379656 [18:15:38] I have an open changeset for the core which got reviewed and the tests are passing, but it is not merged yet (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1089205). Now I am thinking about creating a patch for a very similar feature (T326056, which I also got added to yesterday). Should I wait until the first one is merged until I work on the [18:15:38] T326056: Show a warning on creating double redirect - https://phabricator.wikimedia.org/T326056 [18:15:38] second one, in case there will be any new comments (since those would most likely also apply to the second feature)? Or can I assume the latest version of my patch is fine since it got reviewed already, though not rated? [18:19:20] SomeRandomDevelo: You can work on the other feature if you want. If the next feature depends on code you wrote previously, you should make the second patch dependent on the first (basically in your branch, your new patch is a commit on top of the previous commit, so both of your commits are in your local branch). Keep in mind dependent patches can be kind of confusing in the gerrit interface (Basically [18:19:26] you have to use `git rebase -i` to edit things) [18:19:45] There may be additional feedback on your first patch [18:20:28] I haven't really looked into it, but sometimes people might only have knowledge about certain parts, so they might give feedback about the part they know, but it will be a different person who gives a full review [18:21:04] I have no idea if we have any docs anywhere about how dependent patches work... [18:21:45] Thanks for the response, the patch does not depend on the first, but parts of it would add new lines at the same positions the first line does, which could lead to merge conflicts. [18:22:38] You can just stack them ontop of each other... Or just be prepared to rebase one or the other ;) [18:24:19] https://www.mediawiki.org/wiki/Gerrit/Advanced_usage#Create_a_dependency [18:27:53] Alright, then I'll probably create the second patch as a dependency since it's easier and there wouldn't really be a point in merging the second one after the first, thank you [18:30:04] If they're similar patches, chances are the same person would approve both