In its current implementation, the bayes journal only gets entries to update the atime of tokens which happens during a scan().  This makes sense since the DB is R/O, and we don't need to go updating the atime of all these tokens during what should be a fast process.

However, message/token learns update the atime immediately (which makes sense, the atime is part of the token record, so you may as well update it and the counts at the same time).

However, during a sync_journal(), there's no check of the current atime before a DB update.  So what this means is that scan picks up a token "foo" at count 100.  It writes to the journal "t 100 foo".  Then, autolearning kicks in, but the count is 101 now, so the DB gets updated with foo and atime 101.  Then down the road sync_journal comes along ...  See the problem?

When sync_journal() gets called sometime down the road (currently only whenever an expire run happens or someone specifically calls "sa-learn --rebuild"), the atime of "foo" gets reset to 100.  Now this isn't too big a deal in that case (change of 1 count), but what about a near-worst case:

new db, so last expire is 0
scan() adds "t 100 foo" to the journal
at count 4999, we do a learn which sets token foo to atime 4999
at count 5000, expiry_due() returns true, so we expire automatically.  The journal is synced, and atime for "foo" is set to 100.


This is the byproduct of using the journal for some things and not everything. :(

The solution would be to change BayesStore::tok_touch_token() to see if the current DB atime is >= the new requested atime before it calls tok_put().  aka:

sub tok_touch_token {
  my ($self, $atime, $tok) = @_;
  my ($ts, $th, $oldatime) = $self->tok_get ($tok);

  ## New Check
  return if ($oldatime >= $atime);

  $self->tok_put ($tok, $ts, $th, $atime);
}


I'll put in a patch shortly.