[19:28:43] I'm trying to figure out why, when enabling verbose logs in production on mwdebug and purging or editing a page, there are no INSERT queries logged to parsercache hosts. [19:28:55] I do see the set() operations to MemcachedPeclBag [19:29:33] Best I can tell, the issue is that, due to adoption of DI and moving out of defaults, the Bag instances created by MultiWriteBag ('mysql-multiwrite') no longer have a logger. [19:30:09] and naturally that's not the only thing they lack, they also lack other stuff injected normally from ObjectCache::newFromParams, such as `keyspace` and `asyncHandler`. [19:30:35] But, the reason parsercache isn't corrupted is that MultiWriteBag uses caches[0] for makeKey() and such, and that still happens to have it injected through other means. [19:31:10] But MultiWriteBag->caches[1] (SqlBag) has keyspace=local for example, instead of "enwiki"; lacks asyncHandler, and lacks a logger. [19:31:52] One would think that the rdbms layer as used by SqlBag would have a logger set at least, but it seems not the case either [19:32:30] getConnectionFromServerInfo() passes on $this->logger to Database::factory [19:33:23] Although anything else we would normally get from MWLBFactory is not applied here of course, again, lost after DI adoption. [19:33:35] ( cc\ Amir1 ) [19:37:38] The reason I'm looking into this, is because I am trying to figure out how well parsercache mcrouter-on-host-tier is actually working in practice. We tolerate its 10 second blind TTL in ParserCache, but my gut tells me that for popular pages this means multiple servers will end up perceiving the cache as "wrong" and not even see what it's in the main memc cluster or in PC, but instead needlessly re-parse and needlessly set() another [19:37:38] time. PoolCounter would prevent that from causing an outage under stress, but it seems rather wasteful to even be wanting to parse it in the first place when it's already in memc/sqlbag layers of pcache [19:38:20] the blind TTL thus, whlie in theory reducing get() bandwidth at peak, by default increases set() traffic and user-facing cache misses and more parsing on-demand. [19:39:36] What did I break now? [19:40:20] Not sure but it might be upsert? [19:40:46] nothing I think. I assume it's working, it's just messy and I'm trying to decide where best to fix telemetry. [19:41:54] E.g. we could make ObjectCache::newFromParams be aware of MutliWriteBag/'caches' and give them the same treatment first; or we could manually call newFromParams() in wmf-config likek we do for 'factory' => [ 'ObjectCache', 'getInstance' ], for mcrouter-on-host-tier. [19:42:00] But that feels messy.. [19:43:10] TLDR: The SqlBag that MultiWriteBag creates directly is lacking DI stuff like $logger, $keyspace, $asyncHandler that we normally get via ServiceWiring->ObjectCache::newFromParams [20:08:20] ref T318272 [20:08:20] T318272: MultiWriteBagOStuff caches are missing DI defaults - https://phabricator.wikimedia.org/T318272