Skip to content

Conversation

@tefkah
Copy link
Member

@tefkah tefkah commented Nov 5, 2025

Issue(s) Resolved

#1391

High-level Explanation of PR

This PR overhauls the entire actions system.

Rough outline

  • Action Instances no longer belong to stages, they belong to automations (which belong to stages)
  • Automations can be triggered by a variety of events
  • Automations can be filtered by certain conditions (only jsonata expressions for now)
  • Automations trigger certain actions. For now they can just trigger one action, but all the infrastructure is there for them to trigger multiple

The event system for triggering automations (formerly rules) has also been revamped.
Instead of relying a lot on the app to communicate back and forth with flock directly (or very indirectly), triggering of events has been simplified. We can roughly delineate 3 classes of events

  1. Triggered by the app itself
    • These are the manual and webhook events. there is no communication with flock, the app handles all the automation itself.
  2. Triggered by the database
    • This is the biggest change. Instead of having the automationSucceeded and automationFailed events be triggered through some shady roundtrip to flock as before (basically "scheduling" the event to happen immediately), the database now immediately sends an event to flock once an automation fails or succeeds.
    • flock also no longer sends these requests to core which are roughly "hey a certain event triggered on a stage run all the automations that need to be run if any". flock is a lot dumber now, it just gets a payload which already includes the automation it needs to trigger, and just sends a request to core to do so
    • the PubEntered and PubLeft events are also like this
  3. Delayed events
  • atm only PubInStageForDuration, but a cron event would work the same
  • this is the only one which still uses some back and forth communication between flock and core.
  • roughly
    • PubEnterStage
    • DB figures out if there's a PubInStageForDuration automation in that stage, if so it sends an event to flock to schedule an event
    • flock sends request to core to figure out the event scheduling
    • (we need to do this bc this scheduling may be subject to certain conditions, which only core can eval)
    • core sends request back to flock to run an automation in X amount of time
    • X amount of time passes
    • flock triggers automation in core

Some other things this PR does:

  • improve the layout of the stage manage page
  • massively improve the layout of the automation run page
  • provide an overview of all triggers/functions in core/prisma/consolidated-triggers.sql

Test Plan

Screenshots (if applicable)

Notes

@tefkah tefkah changed the base branch from main to tfk/automations November 5, 2025 20:53
Base automatically changed from tfk/automations to main November 5, 2025 20:59
@github-actions
Copy link

github-actions bot commented Nov 25, 2025

PR Preview Action v1.6.3

🚀 View preview at
https://pubpub.github.io/platform/pr-preview/pr-1397/

Built to branch gh-pages at 2025-12-17 11:35 UTC.
Preview will be ready when the GitHub Pages deployment is complete.

@tefkah tefkah changed the title feat: conditions for automations feat: big automations overhaul Dec 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants