Create database for single run triggers #128

aegbert5 · 2025-12-30T03:44:50Z

This creates the /triggers/:group/:name/onetime/:id route to allow for one-time triggers to be created that don't run on a cron schedule. One-time triggers a different from simple triggers, because they require an ID provided to the route, allowing them to be managed outside of piezo

admin/project/build.properties

tmccombs · 2026-01-09T23:52:02Z

worker/src/main/scala/com/lucidchart/piezo/SingleRunTriggerModel.scala

+          VALUES(?, ?, ?)
+        """.stripMargin,
+      )
+      prepared.setString(1, fireInstanceId)


Should we have a check that this id fits in the column?

The job_name and job_group columns don't have checks on the other job_history or trigger_history tables. Since their columns are VARCHAR(100) NOT NULL, seemed appropriate to use the same for the single_run_trigger_id column. This is definitely something that could be added in a followup PR, but seems outside this PR's scope

worker/src/main/scala/com/lucidchart/piezo/SingleRunTriggerModel.scala

hunterrees · 2026-01-13T22:51:14Z

admin/app/com/lucidchart/piezo/admin/controllers/Triggers.scala

+    if (scheduler.checkExists(jobKey)) {
+      try {
+        // Only run a trigger, if we haven't seen this id before
+        if (singleRunTriggerModel.hasJobAlreadyRun(id, jobKey)) {


Can you help me understand why we can't use existing tables for this? Don't we already keep a trigger history? Could we look to see if the job has ever been triggered before? Or even more specific could we have a new trigger we create each time and then just check if that fired (the later would support us triggering a "one time" job more than once if needed)

The existing job_history and trigger_history tables gets cleaned up periodically by the JobHistoryCleanup.scala . We need to keep a permanent record of "one time" jobs that have triggered, hence why the new table was created

What about updating the JobHistoryCleanup.scala job to exclude these one-time job triggers from its queries? We could have the trigger group or trigger name have something specific that we can filter on.

If we take this approach it means that all of our jobs still go through the same flows and we don't have to create a new database table (which is a bit of a pain).

If we go this route the changes would be:
-Updating the JobHistoryCleanup job and the JobHistoryModel and TriggerHistoryModel classes to exclude a certain trigger group name or trigger name prefix.
-Update piezo sync to configure one time jobs with this trigger group name or trigger name prefix
-Update piezo sync to create a new trigger if the last trigger for the job doesn't match what it expects.

Yeah, that could be done. I don't have a preference for either, but avoiding creating a new table during the release process is nice

hunterrees · 2026-01-13T23:07:07Z

worker/src/main/scala/com/lucidchart/piezo/SingleRunTriggerModel.scala

+            WHERE
+              job_name=?
+              AND job_group=?
+              AND single_run_trigger_id=?


Where is the trigger id generated?

It is provided to the route as a string /triggers/:group/:name/onetime/:id. This allows users to specify their own IDs and determine when to run a 2nd one-time job just by changing the id

We should restrict what the trigger id can be then since it'll be in the path (we don't want spaces for example)

Correct. It'll need to be URL-compliant

It'll need to be URL-compliant

that isn't enough. We also want it to be short enough to fit inside the column. And being in the url it can still have spaces (encoded using %20).

I would like to implement UNIX timestamps for the route, so how about we restrict it to a Long?

hunterrees

I'm not ready to approve yet, but if we keep this approach I don't think we'll need changes. I'd like to discuss the option I outlined of not creating a new table before we proceed.

hunterrees · 2026-01-16T22:41:03Z

admin/app/com/lucidchart/piezo/admin/controllers/Triggers.scala

+    if (scheduler.checkExists(jobKey)) {
+      try {
+        // Only run a trigger, if we haven't seen this id before
+        if (singleRunTriggerModel.hasJobAlreadyRun(id, jobKey)) {


What about updating the JobHistoryCleanup.scala job to exclude these one-time job triggers from its queries? We could have the trigger group or trigger name have something specific that we can filter on.

If we take this approach it means that all of our jobs still go through the same flows and we don't have to create a new database table (which is a bit of a pain).

If we go this route the changes would be:
-Updating the JobHistoryCleanup job and the JobHistoryModel and TriggerHistoryModel classes to exclude a certain trigger group name or trigger name prefix.
-Update piezo sync to configure one time jobs with this trigger group name or trigger name prefix
-Update piezo sync to create a new trigger if the last trigger for the job doesn't match what it expects.

hunterrees · 2026-01-16T22:41:50Z

worker/src/main/scala/com/lucidchart/piezo/SingleRunTriggerModel.scala

+            WHERE
+              job_name=?
+              AND job_group=?
+              AND single_run_trigger_id=?


We should restrict what the trigger id can be then since it'll be in the path (we don't want spaces for example)

tmccombs requested changes Jan 9, 2026

View reviewed changes

aegbert5 force-pushed the create-state-for-single-run-triggers branch 2 times, most recently from b44be52 to 78d57ed Compare January 13, 2026 21:35

aegbert5 requested a review from tmccombs January 13, 2026 21:38

aegbert5 marked this pull request as ready for review January 13, 2026 21:38

aegbert5 force-pushed the create-state-for-single-run-triggers branch 6 times, most recently from a7c8451 to 3aba153 Compare January 13, 2026 21:53

hunterrees self-requested a review January 13, 2026 22:46

hunterrees requested changes Jan 13, 2026

View reviewed changes

aegbert5 requested a review from hunterrees January 15, 2026 22:38

hunterrees requested changes Jan 16, 2026

View reviewed changes

aegbert5 force-pushed the create-state-for-single-run-triggers branch 2 times, most recently from 2d1f1c2 to cd63ac2 Compare January 21, 2026 23:53

Create database for single run triggers

22e8a05

aegbert5 force-pushed the create-state-for-single-run-triggers branch from cd63ac2 to 22e8a05 Compare January 22, 2026 00:40

Create database for single run triggers #128

Are you sure you want to change the base?

Create database for single run triggers #128

Conversation

aegbert5 commented Dec 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aegbert5 Jan 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hunterrees left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

aegbert5 commented Dec 30, 2025 •

edited

Loading

aegbert5 Jan 21, 2026 •

edited

Loading