nexcess/magento-turpentine — pull request #380 by gabrielsomoza (2013-11-27 19:59:43+00:00)
Title: Workaround to bust event area cache after first event is fired.

This fix is for Magento versions EE >= 1.11 and CE > 1.6.0 (and maybe even earlier).

### Context
The problem that led me to this bug was that after adding a product to cart the cart drop-down wouldn't update until the user navigated to a non-cached page (e.g. cart page / checkout / etc). I'm using EE 1.11 and the `header` block has the following ESI configuration:
```xml

private

```
As mentioned in the commen, Magento EE needs the `current_category` registry key to avoid a getEvent() fatal error in the CatalogEvent module - see issue #54 for more information.

However, I don't believe this context triggers the problem described below.

### Problem
Magento caches the events config for each area the first time that the area is loaded. This happens right before `controller_front_init_before`, which is the event Turpentine uses to dynamically add observers to ban the Varnish cache.

So while Turpentine uses the `controller_front_init_before` event to load its observer dynamically, by the time the observers are loaded into the config the `` config area has already been cached into memory. The result is a bug where none of the ESI `flush_cache` events is ever called.

### Solution
* Use model `Nexcessnet_Turpentine_Model_Shim_Mage_Core_Config` to expose a function that will unset the config cache for a given area. This will force Magento to load the event information from the config once again, which is what we want.
* Use that function to clear the config area cache every time after dynamically adding an observer in `Nexcessnet_Turpentine_Model_Shim_Mage_Core_App::shim_addEventObserver()`.

An alternative would be to clear the config area cache only after loading all dynamic modules (e.g. after the `controller_front_init_before` observer has finished its loop). This would clear the event config cache only once and save some CPU cycles. But I don't like that so much from an architectural point of view because it would force everyone that calls `shim_addEventObserver()` to also clear the cache manually.