Apologies as I may not have the precise lingo for these items, but here goes:
I have an application that uses a timer trigger to re-initalize a loop that will act on the next (up to) 100 records that require update based on a query aggregation.
In our DEV instance, with the validation feature flag disabled, we had been operating under the notion that the apps timer-based activity was keeping the session active.
In our PROD instance, with the validation feature flag enabled, it appears the user gets automatically logged out after 15 minutes despite the timer trigger firing to keep the app working.
So far we haven’t observed any record update errors with this behavior, but I am concerned that it might dump out partway through updating a record such that only some but not all required field updates have occurred.
When the automatic timeout/logout occurrs, how does Tulip Player handle pending triggers?
Is there a way to get around this without extending the 15 minutes to a greater value or disabling the feature flag?
What user or other actions might keep a session active to prevent the automatic timeout/logout?
This KB article was recently updated with more clarity around logout behavior in Player - Player Logout Behavior
When the automatic timeout/logout occurrs, how does Tulip Player handle pending triggers?
Essentially when any logout (automatic or manual) occurs, all app triggers are cancelled
Is there a way to get around this without extending the 15 minutes to a greater value or disabling the feature flag?
I don’t believe there is another option besides these 2 you listed
What user or other actions might keep a session active to prevent the automatic timeout/logout?
You should be able to turn off automatic logout if you don’t want this feature! (See Configure Your Tulip Account Settings. ) But essentially as long as Player is running and the device it is running on doesn’t go to sleep, you can stay logged in and have app triggers running.
Tagging @jakerigos to chime in if he has any other suggestions here.
So I think we’ve run it enough times now that I’ve generated an error due to logout occurring mid-trigger. In this case, the pairs of green and purple numbers should match after the app runs to completion, but there was an automatic timeout/logout event whcih appears to have caused a discrepancy.
After inspecting the table data for the two tables involved, it appears that the trigger actions for the table records for the top row of analytic numbers all executed completely, but when the interruption occurred, it happened just after the record ID for the second table (bottom row of analytic numbers) but before any of the other information was transcribed.
Also, the interruption could have occurred after any one of the trigger actions in the sequence, so there could be different degrees of missing data in the first or second table, and the second table record could be missing entirely.
I probably need to create a “repair” app to find and fix such records, but I was wondering if it would be technically possible in a future release of Tulip player to delay the logout until the current trigger has completed.
In Office Hours discussions this week, we contrasted the “danger” of altering the player behavior to wait for a trigger to complete before logout, versus the alternative of having an exception process for the automatic timeout/logout based on station or app or user (e.g. superuser). I think the latter option would largely resolve this issue (excepting any other type of interruption of the player session).
We also discussed the fact that this app could be replaced by Automations, which is the logical evolution of this process once we upgrade to an LTS that has that feature.
I just remembered Sean Joseph and I also discussed this part of the post during Office Hours - I am still left wondering:
What specific user (or other) actions within Tulip player actually serve to reset that automatic timeout/logout timer, and which don’t?
E.G., moving the mouse around, clicking on random elements, clicking a button to fire a trigger, doing things when triggers are actively running vs. when they are not
