Bug report: root-level records (parentId: null) are unstable when inserted directly

Summary

When a takeoff or template record is inserted directly at the project root (parentId: null) via Takeoffs.insert() or Templates.insert(), the resulting record is left in an unstable state. Observed symptoms include: delayed or incorrect display in the UI (invisible for 10+ minutes, or visible with a blank name), and — confirmed today in a controlled, timestamped test — the record cannot be deleted by script: Takeoffs.delete() silently fails, with no error and no removal. In one earlier case, a root-level folder disappeared from the server entirely after 20–30 minutes, orphaning the children that had been created under it.

By contrast, a record that is inserted nested under any existing parent and then promoted to the root via Takeoffs.update(id, {parentId: null}) behaves completely normally, immediately — it can be renamed, moved, or deleted with no issue and no delay.

This strongly suggests the bug is tied to the specific code path used to set parentId: null (a direct insert vs. an update on an existing record), not to root-level records in general.

Environment

• Workspace: STIC
• Project used for the controlled test below: "cégep St-H"
• Access: the zzTakeOff scripting sandbox (run_script, using the Takeoffs / Templates commands) via an MCP integration — but the same instability has also been observed when creating a folder manually through the UI, so it does not appear to be specific to the scripting API.
• Record kind affected: kind: "folder" (the same disappearance pattern has also been observed previously on plain takeoff records inserted at root)

Symptoms observed

1. Delayed UI visibility — a folder inserted directly at root can stay invisible in the takeoffs panel for 10–15+ minutes, across multiple manual refreshes (F5), even though the record is confirmed to exist with correct data via the API the whole time.
2. Blank name in the UI — a folder inserted directly at root can appear immediately in the panel but with a completely blank name. This persisted through a hard refresh (F5) and even through an explicit rename call (Takeoffs.update(id, {properties:{name:{value:"..."}}})) — the UI kept showing a blank name for several minutes afterward, even though the record's name was confirmed correct via the API the entire time.
3. Eventual real disappearance + orphaned children — in one case, a folder inserted directly at root disappeared from the server entirely (Takeoffs.get(id) started returning null) after roughly 28 minutes. Its child record (inserted under it) was not deleted — it survived, with its parentId still pointing at the now-nonexistent folder: a silently orphaned record.
4. Deletion of the record fails silently — confirmed today in a controlled test: calling Takeoffs.delete([id]) (followed by saveAll()) on a folder inserted directly at root does not remove it. No error is returned. A later, separate Takeoffs.get(id) call confirms the record is still present and unchanged, even ~50 seconds after the failed delete call.

How to reproduce

js

// 1. Insert a folder directly at the project root
const F1 = Takeoffs.insert({
  kind: "folder",
  parentId: null,
  properties: { name: { value: "test-direct-root" } }
});
saveAll();
// 2. Try to delete it (immediately, or after waiting several minutes — same result)
Takeoffs.delete([F1._id]);
saveAll();
// 3. In a SEPARATE call, verify:
Takeoffs.get(F1._id);
// -> still returns the full record, not null. The delete had no effect, no error was thrown.

For comparison, the following works immediately and reliably every time:

js

// 1. Insert nested under any existing record
const F3 = Takeoffs.insert({
  kind: "folder",
  parentId: someExistingRecordId,
  properties: { name: { value: "test-nested-then-promoted" } }
});
// 2. Promote it to root via update
Takeoffs.update(F3._id, { parentId: null });
saveAll();
// 3. Delete it — this succeeds immediately, no waiting needed
Takeoffs.delete([F3._id]);
saveAll();
// A later, separate Takeoffs.get(F3._id) correctly returns null.

Evidence from a controlled test (2026-09-28, project "cégep St-H", workspace STIC)

All timestamps UTC.

Time (UTC)ActionRecordResult20:06:56.324Takeoffs.insert({parentId: null, ...})F1 = PCMhKyEQERzkoT33Gcreated20:06:56.324Takeoffs.insert({parentId: <existing>, ...}) then Takeoffs.update(id, {parentId:null})F3 = er8zPnRXoZC7Fnq7ccreated, then promoted to root20:07:04.411Takeoffs.get() on bothF1, F3both exist, correct data20:07:12.972Takeoffs.delete([F1]) + saveAll()F1attempted20:07:18.357Takeoffs.get(F1) (separate call)F1still exists — delete failed silently20:07:47.178Takeoffs.get(F1) (separate call, ~51s after creation)F1still exists — not a delayed delete, a failed one20:07:48.391Takeoffs.delete([F3]) + saveAll()F3attempted20:07:51.856Takeoffs.get(F3) (separate call)F3deleted successfully (null)

A second, independent record (H, id CPsDp8shM6mjK9pMa) was also inserted directly at root and also resisted a direct Takeoffs.delete() call. It was then repaired, with no data loss, by:

1. Relocating it under a real existing parent — Takeoffs.update(id, {parentId: <existingId>}) — confirmed in a separate call.
2. Promoting it back to root — Takeoffs.update(id, {parentId: null}) — confirmed in a separate call.
3. Deleting it — this then succeeded immediately (confirmed null at 20:09:08.861).

This "relocate, then re-promote" sequence has now fixed a stuck root record twice.

We also have an older, real-world example from a separate incident on this account: an orphaned item (id rSvLyePwf6Hy2FWmK) whose parentId (kifZdvMKyWA93Ximv) resolves to a record that no longer exists — consistent with symptom #3 above having occurred previously.

Workaround (validated, currently in use on our end)

1. Never insert a new folder/takeoff directly with parentId: null.
2. Insert it nested under any existing valid record instead.
3. Immediately promote it to the root via Takeoffs.update(id, {parentId: null}) — no waiting required; this path is reliable right away.
4. Verify the parentId change with a separate call before continuing.

For any already-existing root-level record showing the bug (invisible, blank name, or won't delete): relocate it under a real existing parent via update, verify, then either delete it there or promote it back to root via update — both operations are reliable once the record has had a real (non-null) parent at any point, even momentarily.

Impact

• Script-based deletion/reorganization of root-level folders can silently fail, which could mislead an automation or integration into believing a cleanup succeeded when it did not.
• In the worst observed case, a root-level folder disappeared permanently, orphaning its children (they are not deleted, just left pointing at a dead parent) — this could silently affect quantity rollups or reports if not caught.
• We have a reliable workaround in place (above), so this report is for your investigation rather than because we need help unblocking our own workflow.

Hope its not to much details and it help.