I have created a new trigger assembly for a client. It grabs a paginated list of visitors from an API and i have it go through the “trigger - emit new items assembly” and i select the row and unique identifier. The module says it does not store those unique id’s while in the assembly editor so the assembly can be built properly.
But when I create an automation with that new trigger, it does not execute. The debug log is huge so i will only put a snippet
Tue Dec 11 13:28:21.553 EST 2018 – Assembly [Trigger #1 (Fetch Visitors(iCatch) - Fetch Visitors(iCatch))] Module [Trigger - Emit New Items #13] The trigger has been initialized, not processing initial identifier = [8f70ecbd-c6e7-4e0e-b5a2-8376b83f71c5]
I also use the exact same row and id for the actual trigger module.
When polling triggers are first executed, the Trigger - Emit New Items module will just store the initial row identifiers in the database, like that log entry says it is doing.
A “new item” trigger doesn’t consider items to be new until after the trigger runs one time and initializes. Otherwise new polling automations would potentially perform a ton of processing when first created.
Historical data can only be processed via “export automations”. An export automation must have a single trigger whose name starts with the word “Export”.
An example is the Gmail “Export all email addresses labeled” trigger: 0fa839ae912e40728bdd2956b344b6b5
Export triggers should not use the Trigger - Emit New Items module. They just fetch and emit all the historical data that is to be processed.
Export automations can only be run manually from the dashboard. They are intended for one-time bulk processing of historical data.
Export automations will not be timed out, but currently modules that have timeout settings can interrupt the export if they happen to time out. HTTP Transaction and its variants all have timeout settings. Those modules can be configured with infinite timeouts if needed.