impr (cli + hql): fixing upserts, updates, and unique edges + improving CLI init command

[xav-db]

Greptile Summary

This PR fixes three core correctness issues — unique edge enforcement, update-from-variable codegen, and upsert default-value handling — and improves the CLI init command.

Key changes:

• add_e.rs: Rewrites unique-edge enforcement from the overly strict PutFlags::NO_OVERWRITE (which blocked any second same-label edge from a node regardless of target) to an explicit scan of existing out_edges_db entries. The new logic correctly enforces uniqueness only on the (from, label, to) triple. Tests confirm multiple targets and sources are allowed.
• upsert.rs / traversal_steps.rs / traversal_validation.rs: Adds upsert_*_with_defaults variants that apply schema-defined DEFAULT values only during creation; updates correctly ignore them. The code generator now emits upsert_*_with_defaults(...) calls with defaults extracted from schema at analysis time. TraversalType::Update refactored to carry source/source_is_plural, enabling direct variable-to-update codegen without an intermediate read-only traversal.
• init.rs: Changes .gitignore creation from unconditional overwrite to append with line deduplication. However, two bugs remain: (1) unconditional cleanup tracking even when file pre-existed, risking deletion of user content on failure; (2) no guard newline when appending to files lacking a trailing newline, potentially corrupting the last entry.
• Test additions: New unit tests for unique-edge semantics, upsert_*_with_defaults behaviour, and two HQL integration test suites (update_from_var, user_test_13).

Findings:

• .gitignore append logic has two correctness issues that can result in data loss or file corruption.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["add_edge called"] --> B{is_unique flag set?}
    B -->|Yes| C["Scan out_edges_db for from+label key"]
    C --> D{Duplicate to_node found?}
    D -->|Yes| E["Return DuplicateKey error"]
    D -->|No| F["Allocate Edge with v6 UUID"]
    B -->|No| F
    F --> G["Write to edges_db with APPEND"]
    G --> H["Write to out_edges_db with APPEND_DUP"]
    H --> I["Write to in_edges_db with APPEND_DUP"]
    I --> J["Return Ok with Edge value"]

    K["upsert_n_with_defaults called"] --> L{Iterator yields item?}
    L -->|Node exists| M["Update path: apply props only\nignore create_defaults"]
    L -->|Empty iterator| N["Create path: merge_create_props\nprops take priority over defaults"]
    L -->|Error| O["Propagate error"]
    N --> P["Insert new node with merged props"]
    M --> Q["Persist updated node"]

    R["UPDATE from variable"] --> S{Source variable type?}
    S -->|Single node var| T["G::new_mut_from with cloned var"]
    S -->|Collection var| U["G::new_mut_from_iter with cloned iter"]
    S -->|Inline traversal| V["Read-only traversal first then write"]
    T --> W[".update then collect_to_obj"]
    U --> W
    V --> W

Loading

_{Last reviewed commit: 4e46111}

[greptile-apps]

_{15 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Cleanup tracker deletes pre-existing .gitignore on failure

cleanup_tracker.track_file(gitignore_path) is called unconditionally (line 359), regardless of whether the .gitignore file existed before init ran. Previously this was fine because fs::write always created the file fresh. Now that we append to an existing file, if the init command fails at any later step and triggers cleanup, the tracker will delete a .gitignore that the user already had — along with all their existing content.

The tracking should only happen when the file is newly created:

let file_existed = gitignore_path.exists();
let existing = fs::read_to_string(&gitignore_path).unwrap_or_default();
let mut file = fs::OpenOptions::new()
    .create(true)
    .append(true)
    .open(&gitignore_path)?;
for line in gitignore.lines() {
    let trimmed = line.trim();
    if !existing.lines().any(|l| l.trim() == trimmed) {
        writeln!(file, "{}", line)?;
    }
}
if !file_existed {
    cleanup_tracker.track_file(gitignore_path);
}

[greptile-apps]

Appending without a guard newline may corrupt the last line of an existing .gitignore

If the existing .gitignore does not end with a newline (which is technically valid), the first writeln! call (line 356) will concatenate its content onto the last line of the existing file. For example, if the file ends with node_modules (no trailing \n), the result would be node_modules.helix/ instead of two separate entries.

Consider writing a leading newline when the existing file is non-empty and does not already end with one:

let existing = fs::read_to_string(&gitignore_path).unwrap_or_default();
let mut file = fs::OpenOptions::new()
    .create(true)
    .append(true)
    .open(&gitignore_path)?;
// Ensure we start on a fresh line
if !existing.is_empty() && !existing.ends_with('\n') {
    writeln!(file)?;
}
for line in gitignore.lines() {
    let trimmed = line.trim();
    if !existing.lines().any(|l| l.trim() == trimmed) {
        writeln!(file, "{}", line)?;
    }
}