Page MenuHomePhabricator

Flow: in default config posts don't appear
Closed, ResolvedPublic


If you add Flow to MediaWiki-Vagrant, and do no other configuration, you can add topics and posts, but when you later redisplay a topic, e.g. click its permalink icon, you don't see any of its posts! Shahyar, wctaiwan and I all discovered this.

The post does show up in the topic history and the post text is in the flow_revision table, so this is probably a caching issue. Setting $wgFlowUseMemcache = false fixes it (I think it makes Flow use HashBagOStuff). So maybe false should be Flow's default, and overridden by a WMF wmf-config setting.

Another wrinkle is MediaWiki-Vagrant does enable a cache, but it is $wgMainCacheType = 'redis'. So $wgFlowUseMemcache = true should work, since it makes Flow use $wgMemc that ends up being RedisBagOStuff. I'm not sure why it's failing.

Maybe Flow should be flexible and have a $wgFlowCacheType that defaults to CACHE_ANYTHING or CACHE_MEMCACHE, the way system caches like $wgParserCache do. Or it could use $wgMemc all the time, since that misnamed function always does something: it'll use MemcachedPhpBagOStuff or RedisBagOStuff if they're configured, otherwise it falls back to EmptyBagOStuff (dummy cache).

Version: master
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Needs Triage.
bzimport set Reference to bz59941.
bzimport added a subscriber: Unknown Object (MLST).

bingle-admin wrote:

The WMF core features team tracks this bug on Mingle card, but people from the community are welcome to contribute here and in Gerrit.

Change 107348 had a related patch set uploaded by Matthias Mullie:
Don't use complex datatypes as CAS tokens

This was quite a nasty bug, that could only occur in a couple of caches (that have no native CAS)

Bottom line: for caches with non-native CAS, CAS tokens (to confirm if data in cache can reliably be merged without concurrency) are based on the value stored.
When saving, this token is compared with what's currently in cache.

Since it was based on an object, the cache data was actually the same, but was in 2 objects, which did not ===

More details in commit msg of

Change 107380 had a related patch set uploaded by Matthias Mullie:
Don't use complex datatypes as CAS tokens

Change 107348 abandoned by Matthias Mullie:
Don't use complex datatypes as CAS tokens


Change 107380 merged by jenkins-bot:
Don't use complex datatypes as CAS tokens

I tested with my existing Vagrant installation and a pristine box (vagrant destroy followed by vagrant up) with $wgFlowUseMemcache not set. In both cases, I was able to add comments and have them persist, so I'm marking this as fixed.