Convex dashboard does not invoke triggers

[widavies]

This should be pretty self explanatory, but performing a CREATE/DELETE on a table row in the Convex dashboard does not invoke triggers, causing aggregates to get out of sync.

This makes the dashboard functions unavailable to users using aggregates.

Certainly not a major priority, but would be nice at some point. Thanks!

[nipunn1313]

yep - unfortunately this is how it works. There's some info here on how to repair.

https://www.convex.dev/components/aggregate#repair-incorrect-aggregates

[nipunn1313]

Because Triggers work with custom functions, and direct dashboard modifications are at a lower layer, it's not really possible to achieve this unfortunately.

For larger deployments, I'd suggest writing mutations in the function runner and running those to edit objects. Alternately, if it's a smaller deployment, you can reset the aggregate instead whenver you do such edits.

CC @ianmacartney who might have more ideas.

Thx for the report.

[widavies]

@nipunn1313 @ianmacartney As I understand it, Triggers wraps all updates made to a table so the aggregate is kept in sync. I believe the dashboard data edit/delete functions should detect when a Trigger is installed and invoke it.

Otherwise the user is left with the following options:

1. Don't use aggregates
2. Build their own dashboard instead of being able to use Convex's
3. Use the Convex dashboard, but run a repair every time they make an update

[ianmacartney]

You're right.
For completeness, Triggers wraps updates to tables only inside of mutations where you've explicitly wrapped the database.

Currently editing the database through the dashboard does not run any of your code, so that would be a new (and interesting!) capability but not likely short-term.

There are a couple options folks have pursued when they want to have editing live data as part of their day-to-day operations:

• Having a period "consistency checker" that asserts that everything is up to date - this both catches bugs (e.g. you change the calculation but didn't fully backfill), and can surface blips like this. We run a version of this for our internal services, and this was also best practice at Dropbox and other places I've worked, for validating denormalized fields and when things like foreign key constraints fail to scale.
• Modeling it as functions, which can also do audit logging, etc. If you want to avoid boilerplate here, you could use the crud helpers in convex-helpers/crud along with custom functions to quickly define APIs for specific tables. A nice feature here is you can have more logic & validation - e.g. ensuring valid email addresses, saving the old version somewhere.
• Forking the open-source dashboard codebase to add your own behavior & controls. You can then point it at your cloud/prod backend.
• Using an existing library that folks have made that is essentially a convex dashboard clone - I can't remember the name off the top of my head unfortuntately
• Building a dedicated admin page.

I understand the frustration of wanting to move fast and directly edit data without having to worry about triggers.

Interestingly, we've also heard bigger customers go the other way - they want to prevent directly editing the data and want all writes to go through approved / audited channels.