It is, IMHO. As soon as the line "$history = new 
Horde_Core_History($history);" is active, the ActiveSync adapter does 
not find any changes anymore. If I comment out this line and reload 
Apache and I change something, all pending changes are commited to the 
ActiveSync client en bloc. If I re-enable that line and reload Apache, 
the changes pile up again. I will compile a log incl. timestamp when I 
enable / disable that line. If the line is enabled and I reload 
Apache, the pending changes are not found and are not commited to the 
ActiveSync client.

If you prefer, I will open another ticket. No problem.

Still have a small tweak/correction to make to the fix, but this can 
be considered resolved now.

Please keep the discussion here related to the history issue. Either 
open another ticket with full log information, or discuss on the 
mailling list.

I also do not get no UserId 'f' anymore. history_who is a valid string 
now always.

But I have another problem now, which may or may not related to the 
history issue.

After the initial transfer and one test event, there are no 
synchronization anymore.

I've also updated to current PEAR' stable packages:
upgrade ok: channel://pear.horde.org/Horde_Icalendar-2.0.8
upgrade ok: channel://pear.horde.org/Horde_View-2.0.4
upgrade ok: channel://pear.horde.org/Horde_Imap_Client-2.19.6
upgrade ok: channel://pear.horde.org/Horde_ActiveSync-2.15.1

The log file says:
2014-05-16T14:45:24+02:00 INFO: [16187] SyncCache collections refreshed.
2014-05-16T14:45:24+02:00 INFO: [16187] Refreshing @Calendar@ from the cache.
2014-05-16T14:45:24+02:00 INFO: [16187] Initializing state for 
collection: @Calendar@, synckey: {5375fb8d-ba20-477f-bacd-176bc25f42d0}5
2014-05-16T14:45:24+02:00 INFO: [16187] Loading state for synckey 
{5375fb8d-ba20-477f-bacd-176bc25f42d0}5
2014-05-16T14:45:24+02:00 INFO: [16187] Initializing message diff 
engine for @Calendar@ (@Calendar@)
2014-05-16T14:45:24+02:00 INFO: [16187] Using SYNCSTAMP 0 for @Calendar@.
2014-05-16T14:45:24+02:00 INFO: [16187] 
Horde_Core_ActiveSync_Driver::getServerChanges(@Calendar@, 0, 0, 
1399034724, 1)
2014-05-16T14:45:24+02:00 INFO: [16187] Fetching changes for calendar 
using MODSEQ.
2014-05-16T14:45:24+02:00 INFO: [16187] Found 0 message changes in @Calendar@.
2014-05-16T14:45:24+02:00 INFO: [16187] Sleeping for 5 seconds.

When I change an event in my production server, I get log messages like:
Found 1 message changes in @Calendar@.
Found changes!
The test server does not have any "Found changes". At the same time, 
CalDAV synchronizes the added/changed events.

I have added the patch from comment 3 to:

Horde_History             2.3.0   stable

First tested with CalDAV / KDE only:
Before the patch I have gotten 'f' entries in the history_who field, 
after the patch I get no more such entries.

I have also added a logging command to History.php here:

         if (!isset($attributes['who'])) {
             $attributes['who'] = $this->_auth;
         }
         if(!is_string($attributes['who'])) {        /* test userid */

The second if() was triggered _before_ the patch, but never _after_ 
applying the patch. So it looks like your patch fixes the problem for 
CalDAV.

I will setup an ActiveSync testbed and report back.

Actually, I can't reproduce the problem where a 'f' is being sent as 
the username to the prefs_init hook. It is always passed as a null 
value if $registry->getAuth() is false.

If this is still happening for you, please provide a backtrace from 
within the hook so we can see where it is originating from.

For you, both of these issues are most likely from rpc access for 
ActiveSync and/or CALDAV (as you mentioned in your mailing list post). 
This is because we need to bootstrap the 'Horde' application before we 
are fully authenticated. During this process prefs and history are 
both initialized.

The History issue will also occur in current code when we are tracking 
failed login attempts, since we need to initialize the history system 
before we are logged in (and even before we know authentication 
failed). So that is fixed with this last commit.

The prefs situation still needs to be worked on, somehow clearing the 
already instantiated instance in 
Horde_Registry::setAuthenticationSetting().

Changes have been made in Git (master):

commit a599f7e01b65871add15284defd4ba128c7b985f
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date:   Thu May 15 16:40:56 2014 -0400

     Add Horde_Core_History to work around chicken/egg problem.

     Bug: 13105

  framework/Core/lib/Horde/Core/Factory/History.php |    3 +-
  framework/Core/lib/Horde/Core/History.php         |  163 
+++++++++++++++++++++
  framework/Core/package.xml                        |    6 +-
  3 files changed, 169 insertions(+), 3 deletions(-)

http://github.com/horde/horde/commit/a599f7e01b65871add15284defd4ba128c7b985f

This is not the correct solution. This type of logic does not belong 
in a general purpose injector library, nor can we hard code class 
names from another library in this one.

The problem reported on the Horde user list with subject "in 
horde_histories history_who = 'f'" exists in current Horde PEAR 
version, snippet of pear list

Horde_Core                2.11.1  stable
horde                     5.1.6   stable
kronolith                 4.1.5   stable

http://thread.gmane.org/gmane.comp.horde.user/34646/focus=34661

When a CalDAV client access a calendar, kronolith's prefs_init() is 
called for a non-existant user "f" and entries are logged to the 
histories table, where history_who == 'f'. The user information is 
queried, even if you prevent entries with history_who == 'f', e.g. by 
overriding that value in History.php. I mean, entries in histories do 
not cause the call of prefs_init() for user "f".

Attached you find a patch that work arounds both problems. I had 
posted a former, more generic version to the mailing list.

Following Micheal's idea about calling Injector too early, I tested 
what happens if the instance of Horde_History is recreated once the 
authentification is present.

         if($GLOBALS['registry']->getAuth()
         || !in_array($interface, array( 'Horde_History', 'Horde_Core_Hooks' ))
         ) {
               $this->_instances[$interface] = $instance;
                        unset($this->_instances_noauth[$interface]);        // free ressources
         } else {  // make temp instance
                        $this->_instances_noauth[$interface] = $instance;
                }
         return $this;

'Horde_History' suppresses the items with huistory_who == 'f'

'Horde_Core_Hooks' suppresses the calls of prefs_init() with username == "f"