Closed lehrblogger closed 8 years ago
I don't think the result is from the Javascript error. Nothing about this check should be relative to the current time that the tickler script is run. The script should always compare the "baseline" time of the thread to the computed deadline time. If the deadline is before the baseline time, then it would add the appropriate ifPast
amount. Now, in the case of a tickler-label, the baseline time is the date of the most recent message in that thread.
Is it possible that there was a new message in the thread sometime between the deadline (Feb 15 @7am minus FUDGE_FACTOR
) and the time the tickler script actually ran? That's the only scenario that I could see feb15 7am
applied before Feb 15 2016 but interpreted to mean Feb 15 2017.
Also, this is something that I believe would be addressed by your idea to convert relative to absolute labels the first time they are encountered, as long as the absolute labels include the year. On Feb 14 you apply a label feb15 7am
, and the first time the script sees it, the label is changed to feb15 2016 7am
. No matter whether another email shows up in the thread right around the deadline time, or even if the script mysteriously crashes around that time, it will still get delivered in the correct year.
Ah, you are right about the current time! My mistake. That theory is a good one though – it is quite possible that there was a new message in the thread in the interim you described. I’ll close this for now, keep an eye out to see if it happens again, and re-open if I can come up with a reasonable fix, possibly by ignoring messages in threads sent after the earliest time the current run could have started.
I have not forgotten the relative baseline idea in https://github.com/rosulek/gmail-tickler/issues/6#issuecomment-173088998, but just haven't quite gotten the right block of time to sit down and work on it. That solution, combined with a specification of the year, feels like a better fix.
A handful of times threads in my tickler labels have gotten skipped over. For example, I had a thread in a label like
feb15 7am
and it is now 5pm on that day, but my thread was not moved to my inbox.These might correspond with times when the script has encountered a Javascript error (as in https://github.com/rosulek/gmail-tickler/pull/12) or failed to finish for some other reason (I've gotten a couple of
Cannot connect to Gmail
errors). This would prevent the tickler from moving the email the first time, and then the next time it runs, it thinks my label is intended to trigger a year from now.I think the relevant code is here:
(While I haven't used day-of-the-week labels much, I can see a similar issue happening in that case.)
I'm not entirely sure if this needs to be fixed, or what the fix would be. Perhaps a second application of the
FUDGE_FACTOR
in the timestamp comparison? It's hard to imagine that adjustment would thwart an actual user intention, and even if it did, it's better to return things to the inbox too early than too late.