I still have an issue with the trigger tab
After some debugging we found that the manual SQL caused a hidden issue that may affect the triggers page.
Because stopped and active aren’t valid PocketBase select options it breaks validation on any future API writes and messes up the UI.
Here is how you can quickly fix it. Make sure you quit RTILA completely first (check your tray/task manager to ensure no rtila-database process is lingering) so it doesn’t lock the SQLite WAL file then run this in your terminal:
# 1. Fix the invalid trigger chain statuses
sqlite3 ~/.rtila-x/database/data/data.db \
"UPDATE trigger_chain_runs SET status='cancelled', completed_at=strftime('%Y-%m-%d %H:%M:%f','now') WHERE status NOT IN ('pending','running','completed','failed','cancelled','retrying');"
# 2. Clear out stranded queue rows
sqlite3 ~/.rtila-x/database/data/data.db \
"UPDATE queue SET status='failed', error='Abandoned: application closed unexpectedly before the job started.' WHERE status IN ('pending','running');"
# 3. Clean up stranded sessions
sqlite3 ~/.rtila-x/database/data/data.db \
"UPDATE sessions SET status='failed', endTime=strftime('%Y-%m-%d %H:%M:%f','now') WHERE status='running';"
That should get everything back in sync and let the relay write properly again. Please try that to see if it solves the trigger page issue until we release the upcoming version.
This solution does not work. I completely quit RTILA, confirmed that no rtila-database process was still running, and executed all three SQL commands, but the trigger page issue remains. I added some triggers via SQL, I can see it in the interface, but when I want to edit it and save, I have the same error:
Trigger Chain
Failed to update trigger chain: Failed to update
record.
Hi,
Thank you for the SQL cleanup suggestions. I ran all three commands exactly as
described (RTILA fully quit, verified no lingering rtila-database process), but
the trigger page issue remained: chains created via SQL were visible, but any
create/edit from the UI failed with:
Trigger Chain — Failed to create trigger chain: Failed to create record.
Trigger Chain — Failed to update trigger chain: Failed to update record.
I kept digging using the PocketBase request logs, and it turned out there were
TWO separate problems stacked on top of each other. Both are now fixed, and the
Trigger Chain Builder fully works again. Details below, as I believe this
affects other users and your upcoming release.
Problem 1 — null field values crashing the Builder UI
Original symptom: opening the Builder crashed the page
(“An unexpected error occurred. Please try refreshing the application.”,
stack: @tauri://localhost/assets/TriggerChainBuilder-B3EgMefV.js:1:119617).
Cause: records containing null values where the Builder expects real values —
owner: null, retry_policy: null, input_schema: null, output_schema: null,
triggers: null, plus empty created/updated dates (from manual SQL inserts and a
schema edit that had changed owner to DEFAULT NULL).
Fix — normalized all existing records:
UPDATE trigger_chains SET owner='<user_id>' WHERE owner IS NULL OR owner='';
UPDATE trigger_chains SET triggers='[]' WHERE triggers IS NULL;
UPDATE trigger_chains SET retry_policy='{}' WHERE retry_policy IS NULL;
UPDATE trigger_chains SET input_schema='{}' WHERE input_schema IS NULL;
UPDATE trigger_chains SET output_schema='{}' WHERE output_schema IS NULL;
UPDATE trigger_chains SET created=strftime('%Y-%m-%d %H:%M:%S.000Z','now')
WHERE created IS NULL OR created='';
UPDATE trigger_chains SET updated=strftime('%Y-%m-%d %H:%M:%S.000Z','now')
WHERE updated IS NULL OR updated='';
CREATE INDEX IF NOT EXISTS idx_trigger_chains_owner ON trigger_chains (owner);
After this, the Builder opened without crashing.
Problem 2 — triggers marked Required in the schema, but the Builder sends it empty
With Problem 1 fixed, every create/update from the Builder was still rejected
with a 400. The PocketBase logs revealed the real reason, which the UI never
displayed:
POST /api/collections/trigger_chains/records → 400
details: { "triggers": "cannot be blank" }
error: "Failed to create record."
PATCH /api/collections/trigger_chains/records/testchain001 → 400
details: { "triggers": "cannot be blank" }
error: "Failed to update record."
Key facts:
- Every failing request was properly authenticated (authId ye3yiqst2vx07ks),
so this was NOT an API-rule problem. - A curl create with
"triggers": []succeeded, while the Builder’s own
request failed → the collection schema markstriggersas Required, but the
Builder sends an empty/null triggers value when no trigger is configured yet.
Workaround applied until you ship a fix:
-
Cleared the Required flag on the JSON fields of trigger_chains
(triggers, retry_policy, input_schema, output_schema) via the superuser API
(PATCH /api/collections/trigger_chains, required: false). -
Added a permanent safety hook
(~/.rtila-x/database/hooks/zz_triggers_safety.pb.js) that coerces an empty
triggers value to a valid before validation, so records created by the
Builder always store a proper JSON array even if a future update restores
the Required flag:onRecordCreateRequest((e) => {
if (e.record.collection().name === “trigger_chains”) {
const t = e.record.get(“triggers”);
if (t === null || typeof t === “undefined” || t === “”) {
e.record.set(“triggers”, );
}
}
e.next();
});
// (same logic registered on onRecordUpdateRequest)
Result
- Creating a new trigger chain from the UI:
works - Editing/saving an existing chain from the Builder: works
- Opening the Builder no longer crashes:
Suggestions for the upcoming version
- The Builder should send
"triggers": [](never null/missing) on create and
update — ortriggersshould not be Required in the shipped schema. - The Builder crashes when JSON fields (triggers, retry_policy, input_schema,
output_schema) are null — defensive parsing would prevent the “unexpected
error” crash for anyone with manually inserted records. - The UI error message discards PocketBase’s validation details. Surfacing the
dataobject of the 400 response (“triggers: cannot be blank”) would have
saved hours of debugging. - Minor: since some hook files are regenerated at each launch, it would help
to document which hook filenames are safe for user customization.
Environment: RTILA Studio (Tauri) on macOS 26.6.1, embedded rtila-database
(PocketBase) on 127.0.0.1:8880.
Happy to share the full request-log export or anything else if useful. Your
cleanup commands were still valuable to tidy up stale runs/queue rows/sessions
— they just weren’t the cause of this one.
here is a part of the request-log
[
{
"id": "qlfyha1fh4zubdn",
"created": "2026-09-14 10:12:56.309Z",
"data": {
"auth": "users",
"authId": "ye3yiqst2vx07ks",
"details": {
"triggers": "cannot be blank"
},
"error": "Failed to create record.",
"execTime": 3.778708,
"method": "POST",
"referer": "",
"status": 400,
"type": "request",
"url": "/api/collections/trigger_chains/records",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko)"
},
"message": "POST /api/collections/trigger_chains/records",
"level": 8
},
{
"id": "8p7ndk7q8au9v89",
"created": "2026-09-14 10:12:39.692Z",
"data": {
"auth": "users",
"authId": "ye3yiqst2vx07ks",
"details": {
"triggers": "cannot be blank"
},
"error": "Failed to create record.",
"execTime": 1.14875,
"method": "POST",
"referer": "",
"status": 400,
"type": "request",
"url": "/api/collections/trigger_chains/records",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko)"
},
"message": "POST /api/collections/trigger_chains/records",
"level": 8
},
{
"id": "bp61fzffg4gm86p",
"created": "2026-09-14 10:07:38.263Z",
"data": {
"auth": "users",
"authId": "ye3yiqst2vx07ks",
"details": {
"triggers": "cannot be blank"
},
"error": "Failed to update record.",
"execTime": 3.190584,
"method": "PATCH",
"referer": "",
"status": 400,
"type": "request",
"url": "/api/collections/trigger_chains/records/testchain001",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko)"
},
"message": "PATCH /api/collections/trigger_chains/records/testchain001",
"level": 8
},
Thanks again for your help!
Alexandre-Kamel
I have still an issue, with updating/deleting nodes, inside a trigger. I will let you know what I can find
Hi,
Quick follow-up to my previous report — one correction to the workaround I
described, and one new bug found while testing further.
Correction — the hook workaround is NOT permanent
We discovered that RTILA regenerates the entire hooks directory
(~/.rtila-x/database/hooks/) at every launch and silently deletes any file it
does not manage. After a restart, the folder only contains RTILA’s 11
canonical files, all freshly rewritten with the same timestamp:
audit_log.pb.js, cron_jobs.pb.js, license_validate.pb.js,
owner_assignment.pb.js, profile_create.pb.js,
project_sync_collections.pb.js, project_versioning.pb.js,
remote_execution.pb.js, user_login_timestamp.pb.js, utils.js,
webhook_receiver.pb.js
Consequences:
- The zz_triggers_safety.pb.js hook I described gets deleted on every launch,
so that workaround does not survive restarts. (A previously user-created
owner_bypass.pb.js was wiped the same way.) - As a result, after a Builder save the stored record goes back to
input_schema: null / output_schema: null — we confirmed this by dumping the
record right after a Builder save (retry_policy was properly filled, but
input_schema and output_schema were null).
So a durable fix cannot rely on custom hook files. The cleanest fix is
upstream: the Builder should never send null for triggers, input_schema and
output_schema (send and {} instead) — that single change would have
prevented this entire chain of issues.
This doesn’t change the root-cause analysis in my previous message: the
Required flag on triggers remains the confirmed cause of the original
“Failed to create/update record.” errors, and clearing it did fix chain-level
creation and editing (both work now).
New bug — Builder crashes when deleting or modifying a NODE inside a chain
Reproduction (100% of the time, even on a brand-new chain created via the
Builder, with clean data):
- Create a new trigger chain in the Builder
- Add a node (e.g., launch_project)
- Modify the node → the change IS saved (persists after reload), but the UI
crashes immediately after - Delete the node → the UI crashes immediately, and the change is NOT saved
(the node is still there after reload)
Error dialog stack (same module as the original crash):
ref@tauri://localhost/assets/TriggerChainBuilder-B3EgMefV.js:1:129589
Sn@tauri://localhost/assets/index-CZwNh2d8.js:2:21619
nn@tauri://localhost/assets/index-CZwNh2d8.js:2:27082
We@tauri://localhost/assets/index-CZwNh2d8.js:2:50421
ct@tauri://localhost/assets/index-CZwNh2d8.js:2:51518
We@tauri://localhost/assets/index-CZwNh2d8.js:2:50773
w@tauri://localhost/assets/index-CZwNh2d8.js:2:42483
k@tauri://localhost/assets/index-CZwNh2d8.js:2:45431
O@tauri://localhost/assets/index-CZwNh2d8.js:2:44802
E@tauri://localhost/assets/index-CZwNh2d8.js:2:43466
w@tauri://localhost/assets/index-CZwNh2d8.js:2:42727
U@tauri://localhost/assets/index-CZwNh2d8.js:2:46954
run@tauri://localhost/assets/index-CZwNh2d8.js:2:6460
runIfDirty@tauri://localhost/assets/index-CZwNh2d8.js:2:6771
Sn@tauri://localhost/assets/index-CZwNh2d8.js:2:21627
zl@tauri://localhost/assets/index-CZwNh2d8.js:2:23444
The run/runIfDirty/zl frames indicate a crash during a reactive re-render.
During the crash window, the PocketBase logs show no failed requests at all
(no 4xx/5xx) — the failure is purely client-side.
Corrupted data is ruled out: brand-new chain, node saved by the Builder
itself ({“type”: “launch_project”, “params”: {…},
“output_variable_name”: “launch_project_1_queue_id”}), and we even manually
set input_schema/output_schema to {} before testing — the crash persists.
One observation that may help your investigation: after a Builder save, the
stored trigger objects contain no id field (server format: type / params /
output_variable_name). If the Builder’s node delete/modify handlers look up
nodes by id after a save or realtime update, the lookup would fail — which
would match the symptoms exactly (add works, modify saves then crashes,
delete crashes before saving).
Chain-level operations (create chain, edit fields, save) work fine.
Happy to provide full log exports and data dumps if useful.
Thanks!
Alexandre-Kamel
Hi Alexandre,
First of all, thank you so much for this incredibly detailed and thorough follow up. You should genuinely be proud of this level of investigative work! Your deep dive into the logs, client side behavior and data structures is top tier and immensely helpful to our team.
Regarding the hook workaround not being permanent, you completely nailed exactly what is happening. In our last update, we implemented a universal fix that always clears the destination hooks and migrations folders upon launch. We did this to guarantee that absolutely no orphaned or outdated files from previous versions are left behind to cause conflicts. While this makes the core application much more solid and reliable, the trade off, as you discovered is that it prevents custom tweaking and makes local debugging at that level much more limited.
Because of your extensive testing, you perfectly caught that the true, durable fix needs to be applied directly at the source code level. You are completely right: the Builder needs to send empty objects {} instead of null for triggers, input_schema and output_schema. We are going to implement this exact fix in the codebase and will be releasing a new version soon to resolve this chain of issues.
Your additional observation regarding the Builder crash when modifying or deleting a node is also brilliant. Your theory about the reactive UI crashing due to a missing id field during the node lookup perfectly matches the client side symptoms you tracked down. We are using your reproduction steps to patch this up for the next release as well.
I also want to let you know that we have already applied many of your previous suggestions to the current version. Your insights have been incredibly valuable to our development process. Please, never hesitate to share any other suggestions, feedback or bug reports you might have.
Thanks again for helping us make the software better!
Hi,
Thank you so much for the kind words — and thank YOU for reading through
everything, acting on it so quickly, and already integrating many of the
previous suggestions into the current version. Seeing feedback turn into
shipped improvements that fast is rare and genuinely appreciated.
I have to be transparent about one thing: most of the heavy debugging was
done with the help of LLMs (GLM 5.2/3 are great). My role was mostly steering the
investigation, running the tests on my machine, and connecting the dots
between the logs and the UI behavior. 
Where things stand on my side
- Everything is functional: creating/editing chains, adding nodes, and
deleting/modifying nodes — all changes now save and persist correctly. - The only remaining item is the cosmetic UI crash dialog after each node
delete/modify (the frontend re-render issue we discussed). I have to quit rtila and reopen it. - As a durable local guard (since custom hook files can’t survive the hooks
purge — which I now understand is by design), I installed two SQLite
triggers directly in data.db (trg_tc_norm_ins / trg_tc_norm_upd) that
coerce any null/blank triggers, retry_policy, input_schema and
output_schema to / {} on every write. They survive restarts and are
invisible to the app. I’ll remove them as soon as your fixed version
ships, so I can validate your fix cleanly.
One small suggestion for the upcoming release
If possible, ship a tiny data migration alongside the code fix, to normalize
records that already contain nulls — users who hit this bug before the fix
will still have corrupted records stored (the code fix prevents new ones,
but won’t repair existing ones).
One feature request
Would it be possible to add an export option for records in PocketBase (CSV and/or JSON)
in the admin dashboard, similar to the existing log export? Being able to
export any collection’s records would help a lot for backups, external
analysis and support workflows. Honestly, the log export feature is what
made this whole investigation possible — having the same for records (e.g.,
trigger_chains) would be a fantastic addition.
I’m really looking forward to the next update. This software has enormous
potential compared to every other automation tool I’ve tried, and I genuinely
enjoy using it for my projects. When the new version lands, I’ll gladly test
both fixes and confirm.
Thanks again for building such a responsive, high-quality product!
Best,
Alexandre-Kamel
Update 8.3.213 is now live and resolves the issues reported above. Could you please confirm if this update fixes the issue for you? Thank you for your feedback and support!
The triggers don’t have any crashes in saved/edited it, but I will test it more later. But I notice the JSON still has some “null”. May be an issue but not sure.
{
"items": [
{
"id": "7ag94onclc0fz7w",
"input_schema": null,
"name": "Test Trigger",
"output_schema": null,
"retry_policy": {
"backoff_ms": 1000,
"backoff_multiplier": 2,
"max_retries": 0
},
"triggers": [
{
"output_variable_name": "launch_project_1_queue_id",
"params": {
"project_id": "",
"timeout_seconds": 300,
"variables": {},
"wait_for_completion": false
},
"type": "launch_project"
},
{
"output_variable_name": "export_to_file_2_file_path",
"params": {
"format": "csv",
"mode": "overwrite",
"output_path": ""
},
"type": "export_to_file"
},
{
"output_variable_name": "generic_webhook_3_status_code",
"params": {
"headers": {},
"method": "POST",
"payload": "",
"timeout": 30,
"url": ""
},
"type": "generic_webhook"
},
{
"output_variable_name": "send_email_4_response",
"params": {
"attachment_path": "",
"body": "",
"password": "",
"recipient_email": "",
"sender_email": "",
"smtp_port": 587,
"smtp_server": "",
"subject": "",
"use_tls": true,
"username": ""
},
"type": "send_email"
},
{
"output_variable_name": "google_sheets_5_cell_value",
"params": {
"cell": "",
"data": "",
"gcp_credentials_json": "",
"operation": "",
"parent_folder_id": "",
"parent_folder_name": "",
"share_with_email": "",
"spreadsheet_id": "",
"spreadsheet_title": "",
"worksheet_name": "Sheet1"
},
"type": "google_sheets"
}
]
}
],
"page": 1,
"perPage": 10,
"totalItems": 1,
"totalPages": 1
}
Thank you for your feedback Alexandre. To help you with the new trigger chain, I have created two demo projects and a demo chain to handle the orchestration.
The core idea is that we launch the first project using the launch_project trigger to extract the links. Then, we consume only a specific piece of data (in our case, the URL column) using the read_project_dataset trigger. Next, we use a transform trigger to clean the data and pass it to the second project. The second project uses these URLs as variables and takes advantage of concurrent instances to process all of them simultaneously.
While this is just a sample workflow, this concept unlocks unlimited opportunities.
I have attached the two demo projects (Books_To_Scrape_Details.json and Books_To_Scrape_First_Page_URLs.json). Start by importing them, then import the trigger chain (trigger_chain_example_20260921094210.json) and follow the video below to quickly assign the projects to the trigger.
Books_To_Scrape_First_Page_URLs.json (829 Bytes)
Books_To_Scrape_Details.json (1.6 KB)
trigger_chain_example_20260921094210.json (1.7 KB)