Log contains multiple "ham" messages, but no comment exists

I noticed that this happens when the commenter previews the comment. I'm not sure, however, whether this is the correct behavior or not.

Similar case here.
Mollom says it's unsure, it logs the comment, a link to the node, but there is no comment there, not even in the comment queue, so how can the comment be approved/disapprove?

I've just noticed the same thing with version 6.x-1.5 (so updated this ticket). Seemingly the visitor tried to submit their comment four times over a period of abut 5 minutes before giving up.

It's possible they only previewed and didn't know to save the comment - it's possible, but seems a bit unlikely.

In all cases, the 'variables' field of the {watchdog} table contains a perfectly good looking comment, yet it doesn't show up in the comments table (not even as unpublished).

Here's a typical 'details' page of a watchdog message (in fact, all four are the same except for the time):

Type : mollom
Date: Saturday, October 25, 2008 - 12:00
User : Anonymous Coward
Location: http://www.coofercat.com/comment/reply/730/2865
Referrer: http://www.coofercat.com/comment/reply/730/2865
Message: Ham: i an a c-link driver at our depot we are not given the phones until we have scanned all our parcels so we cannot raid the parcels before we ar relesed all so i am lucky to del in the area that i live in so know the area very well i avarage 70 drops a day & if card 6 drops a day it is a bad day i do not like carding but it can not be helped wen people order stuff they do not relise that it may be dev in less then 24 hoursso may not be ini am sayin that we dont some times mess up . but remember your parcel is one of 1.000s that are delt with daley
Severity: notice
Hostname: 84.13.45.143
Operations:

I've had a look in the {mollom} table, and it doesn't have anything that's not in the {comments} table, so has no extra information to help us.

As a possible way to avoid this, is there perhaps a way that Mollom could put every message into the {comments} table when submitted, but perhaps just unpublish the things it thinks are spam? Obviously, having to 'moderate' one's comments is tedious and not why we use Mollom, but it might be a 'super safe' option for those of us worried about losing comments, and a way to catch whatever is causing this.

...Looking in greater detail, might give us a bit of extra info. It does look to be related to 'preview' traffic. A couple of comments that have made it onto the site successfully are listed more than once in the Watchdog log (as "Ham: ..."). That would suggest that previews generate these messages just as submits do.

Looking in the code, it seems the only place that "Ham: " log messages are generated are in a validate hook. That would suggest Mollom checks comments (actually, all content) in preview and submit phases.

Assuming I'm right about this, I would suggest that the log message changes for preview and submit phases. At least that would tell us if the people submitting these comments are just not pressing 'submit' or if we are indeed losing comments.

coofercat, you are right that Mollom performs these checks in both preview and submit handlers. I realize that that might be confusing and we should probably look into making it less confusing.

subscribed

Just happened today: Funny thing dblog says Ham, but mollom itsself said spam:

Array
(
    [spam] => 1
    [profanity] => 0
    [quality] => 0.339
    [session_id] => 100608358be019d60d
)

Sometimes spammers 'Preview' but don't 'Submit' the comment. Some versions of the Mollom module, filter on Preview as well as on Submit. Automated tools aren't always that smart -- they press the first button they can click on. ;)

No it wasn't a spammer. The comment was actually a "ham" one...

But I don't know whether he just previewed...

I may be wrong, but starting from Drupal 6, Mollom should only perform textual analysis (which would lead to such "ham" log messages) until a definite validation result can be drawn, i.e., the post is either ham, unsure (fallback to captcha), or spam. No definite result can be drawn in case of a form validation error, potentially elsewhere in the form, in which case we send the values again for textual analysis. If we reached a definite result of ham or spam, the module should no longer contact Mollom servers for validation, but handle further form processing locally only. In case of spam, the form must not be able to submit. In case of ham, the module just records the returned Mollom session id in the database to map it to the submitted post.

Though I also slightly recall a monster hiccup regarding these form validation steps. Since we need to rewrite that portion of the code for #364575: Support alternative spam rejection methods than a CAPTCHA (e.g. unpublishing) and related issues anyway in the coming days, it does not hurt to properly ensure our expectations here.

@Dries: In light of my first paragraph ^^, can we specify our expectations? Any objections or amendments to mine?

What we definitely could do is to add (yet) another watchdog() into Mollom's global form submit handler, so as to log/report successful form submission. (Though that should be visible through watchdog messages of the actual module owning the form already...?)

I cannot follow the thread entirely, but I have several coments on my site that are 'ham' but are not published. This is worse than having spam published. You punish the good ones. That is justice upside down.

Re #12: it means people previewed the comment but did not submit it. Sometimes people decide to do that. Has nothing to do with Mollom.

I think that the main topic of this issue - not being able to track whether a post was subsequently submitted/analyzed by Mollom in the logs - has been fixed via #907016: Profanity checking does not always block profane posts, which is already part of 6.x-1.14.

To allow site administrators to manually double-check whether a post was really spam or not, we are going to implement #881534: Allow to unpublish spam posts instead of rejecting

Thus, marking as fixed.