Action triggers repeat_delay looking at unrelated events

Bug #1823983 reported by Steve Callender on 2019-04-09
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

Tested in Evergreen 3.1

I'm seeing events blocked from being created if there is a repeat_delay but a different event falls into that window and the events share the same target ID.

I've been testing with the Expiration Courtesy Notices.

event def 110
Hook au.expired (or expired on early setups)
repeat_delay 300 days

This should fire off if there no no 110 events in the last 300 days, and there isn't.

However, there is a single event from 3 months ago for a different trigger,

event def 32
hook biblio.format.record_entry.print

So it looks like Evergreen needs to not just find events with a matching target, but also limit them to the event definition as well.

It looks like it only cares about the target value, [{"active":"t","home_ou":{"in":{"from":"aou","where":{"id":2},"select":{"aou":[{"transform":"actor.org_unit_descendants","result_field":"id","column":"id"}]}}},"deleted":"f","-and":[{"+atev":{"id":null}}],"expire_date":{"between":["2019-03-06 10:05:03+0000","2019-04-05 10:05:03+0000"]}},{"join":{"atev":{"filter":{"start_time":{">":"2018-05-09 10:05:03+0000"}},"fkey":"id","field":"target","type":"left"}}}]

Mike Rylander (mrylander) wrote :

This turns out to be a very straight-forward fix. Branch here:;a=shortlog;h=refs/heads/user/miker/lp-1823983-keep_event_id_filter_on_delay_repeat_check

From the commit message:

This bug has existed since the repeat_delay feature was added, but likely only rarely was triggered because most events don't have a repeat_delay, and those that do don't interact with the same target. However, as more repeatable event definitions are created, inappropriate interaction becomes more likely.

In this commit we avoid overwriting the whole join condition clause, which already contains an event definition id filter and needs to retain it.

Included is an unrelated change that uses the new-ish form of interval_to_seconds that avoids DST boundary shifting issues by passing a context DateTime object as the second parameter.

Changed in evergreen:
status: New → Confirmed
milestone: none → 3.3.1
milestone: 3.3.1 → none
tags: added: actiontrigger pullrequest
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers