graphql-engine
graphql-engine copied to clipboard
pause event triggers
Sometimes for seeding data or general dev functionalities, we may not want the event trigger to be invoked. Currently, the only way to stop events from creating/delivering is by dropping the event trigger. We can perhaps give a pause functionality to pause an event trigger without needing to drop it.
@tirumaraiselvan hi bro, any updates on this?
@tirumaraiselvan What is the status on this feature? In a development environment where we are constantly seeding our DB this causes traffic we would prefer to not have to process. Especially so after the v1.2 upgrade to how migrations are handled.
+1
I would also like this feature. I am not sure if this is exactly the feature that should be built for my use but it could be useful. I crashed all of the things in my system by accidentally creating an infinite loop with a webhook. A serverless function was being called to do some validation on each row and validate it by setting a column to true. Accidentally "update_at" was left selected on the update trigger. This caused a cascade of problems.
The trigger went infnite loop. Hasura console became unsreponsive because it was processing something like 100k requests / second on a small server. The database crashed because it was quickly populated with about 4 million rows of event_logs. So the database was then unaccessable from client. Eventually everything had to be shutdown. Database resized to gain access. Manually delete all logs on postgres and delete triggers / functions and hand undo metadata / migrations in hasura to get it to stop trying to restart infinite loops.
Essentially I want an off switch in case of emergency or a way to protect from this error in the future and am unsure how to do it. So having a cli command that could suspend webhooks kinda like the "Throttle" button provided in aws lambda console could be useful in case of emergency as well as database seeding etc as mentioned above.
Are there any plans on implementing this feature ?
+1
A much needed feature, some of the triggers might send emails and sms, others track change history so seeding causes a lot of chaos
Since no one has addressed this issue I can suggest my workaround to the issue. Since hasura's events are just wrappers around postgres' events you can disable the event inside your seed files.
Add at the top of the file that has any associated triggers set session_replication_role to replica;
and then set session_replication_role to default;
at the bottom of it.
You can add separate files before and after your seed files for those two commands, but adding it per file works better for my personal use case
+1
I noticed this issue was opened in 2019, and it makes sense. Currently, I have multiple event triggers to a specific table, it would be even nicer to determine which events NOT to trigger programmatically instead of disabling all in case Hasura team is working on a solution for this.
This solution is needed.
+1
Are there any plans to implement this function?
+1
+1
+1