View Issue Details

IDProjectCategoryView StatusLast Update
0017291phplist applicationMessage Send Processpublic09-10-14 13:04
Reporterduncanc 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Version3.0.6 
Target Version3.0.9Fixed in Version3.0.9 
Summary0017291: Message selection using embargo time
DescriptionThe sql to select messages in actions/processqueue.php selects those messages whose embargo time is less that the current time.

Should that not also include messages whose embargo time is equal to the current time?
See the processing at line 471

$query
= " select id"
. " from ${tables['message']}"
. " where status not in ('draft', 'sent', 'prepared', 'suspended')"
. " and embargo < current_timestamp"
. " order by entered ".$messagelimit;
TagsNo tags attached.

Activities

michiel

04-08-14 20:22

manager   ~0054497

current_timestamp is in seconds, so adding the = would make a difference of a second.

mysql> select current_timestamp;
+---------------------+
| current_timestamp |
+---------------------+
| 2014-08-04 21:20:23 |
+---------------------+


But if you mean that might solve 0017290 then it may help, but won't solve perfectly. It would require the crons to fire off perfectly as well, which they don't either.

The only option is to run the cron more frequently. I run it every minute.

duncanc

04-08-14 20:32

developer   ~0054498

No, this is not related to 17290.

But I don't understand the point you are making.
If the message embargo time is 09:30:00 and the current time is also 09:30:00 then the message will not be selected. My question is whether it should, by the meaning of the embargo time, i.e. the message will not be sent before the embargo time.

Unless I am missing something?

michiel

04-08-14 20:39

manager   ~0054499

The point I'm making is that even if, and I have no idea what the exact definition of embargo is, it should be sent at 09:30:00 and isn't, it will be at 09:30:01 which is only a second later.

If the definition of embargo is "should not be sent before" then it can be included. If the definition is "should be sent before and inclusive" then it's fine as it is.

duncanc

04-08-14 20:49

developer   ~0054500

The help text for embargo on the Schedule page has "You can embargo a message so it is not sent before the date and time you indicate".

So I think that it is reasonable to expect that the message would be selected if processqueue ran at exactly that embargo time.

michiel

04-08-14 21:12

manager   ~0054501

I guess normal enbargos deal with hours, not seconds.

http://en.wikipedia.org/wiki/News_embargo

quarreling over a second is what programmers do :-)

duncanc

10-08-14 16:45

developer   ~0054537

The usual interpretation of "embargo" is not before, as in the wikipedia article that you referred to.

Currently if the message embargo time is 09:30:00 and processqueue runs at 09:30:00 then the message will not be selected. It is not a case of waiting one further second, but waiting until the next run of processqueue before the message will be sent.

gingerling

11-08-14 09:47

manager   ~0054540

Bearing in mind I find time difficult, and don't understand all the technicalities of this discussion, my view is that:

From a users perspective, I would be annoyed if one second discrepancy was stopping a campaign from going out when I asked, and it would not occur to me that this would happen. I am also not sure there would be many users who would be annoyed the other way round, who would say "but there was one second difference it should never have gone out then"

michiel

09-10-14 13:04

manager   ~0055382

https://github.com/michield/phplist/commit/cbe75cefd4ad4a269668255bb20d3b14505b39bf