[AlbinoGeek]

Problem

Removing one entry from an array of tables deletes the sub-tables of every other entry too.

import { parse, patch } from '@decimalturn/toml-patch'

const src = `[[route]]
id = "a"
[route.args]
x = 1

[[route]]
id = "b"
[route.args]
y = 2
`
const updated = parse(src)
updated.route.splice(1, 1)
console.log(patch(src, updated))

On 3.3.0 and on latest (b092c65) this prints:

[[route]]
id = "a"

route[0].args is gone. diff() is correct here: it emits one Remove ["route", 1].

Cause

In src/patch.ts, the "Same repair for a removed SECTION header" block (added for fuzz seed 136292) removes every document-level sibling whose key extends the removed header's key. That is right for a [table]. A [[table]] entry, though, only owns the [route.args] sections between its own header and the next [[route]] header, and the sweep was also catching the other entries' sections.

Fix

For a TableArray node, the sweep now only looks at siblings between the entry and the next [[...]] header with the same key. The behaviour for [table] headers is unchanged.

Tests

• New test in src/__tests__/patch.test.ts: removes each of three [[route]] entries that all have [route.args], and checks that parse(patch(...)) equals the updated object. It fails before the fix and passes after.
• pnpm run typecheck, pnpm run lint, pnpm run build, vitest run (63 files, 3412 passed, submodules initialised) and pnpm run test:js (131 passed) all pass locally. I ran them with bun instead of pnpm.
• Also checked against a 36 KB real-world config (23 [[route]] entries, many with [route.args] and comments): removing one entry now changes only that entry's own lines.

CHANGELOG.md has an entry under Unreleased / Fixed.

🤖 Generated with Claude Code

[AlbinoGeek]

[ It was breaking a LOT of our TOML files, bahaha. ]

[Copilot]

🟡 Changes recommended

Nested-array removal can still cross an ancestor entry boundary and delete surviving sub-tables.

1 open issue

• Stop ownership scans at ancestor array entries · New

What changed in this PR

This PR limits sub-table cleanup when removing an array-of-tables entry, preserving sections owned by other entries.

Changes:

• Bounds cleanup at the next same-key array header.
• Adds regression coverage for removing each of three entries.
• Documents the fix in the changelog.

File	Description
src/​patch.ts	Limits the sibling cleanup range.
src/​__tests__/​patch.test.ts	Tests preservation of surviving entries’ sub-tables.
CHANGELOG.md	Records the fix under Unreleased.

_{Review effort: Balanced}

[DecimalTurn]

Thanks for this fix! I'm planning to check why this wasn't caught earlier during fuzz testing, but I'll merge this in the meantime, so this specific bug is handled correctly, but I'm guesing there might be some other related ones related to some deletions in complex AOT nesting structures.

[AlbinoGeek]

Awesome thank you, I can drop the vendored one now :) Yeah I was confused too, you have a lot of testing, but for whatever reason when I ran this against a large catalog we have, which is like 65MB, it tried to delete nearly all of it.

…

On Sat, Oct 17, 2026, 11:58 Martin Leduc ***@***.***> wrote: Merged #321 <#321> into latest. — Reply to this email directly, view it on GitHub <#321?email_source=notifications&email_token=AAOSNPOULZKEBNMF4Y4UFA35UO6MLA5CNFSNUABQM5UWIORPF5TWS5BNNB2WEL2JONZXKZKFOZSW45CON52GSZTJMNQXI2LPNYXTGMZVGM2TOMJUGI2DJJTSMVQXG33OUZQXK5DIN5ZKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#event-33535714244>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOSNPNLMPKKQST3JJDSYET5UO6MLAVCNFSNUABFKJSXA33TNF2G64TZHM4TKNBSG44DEMBQHNEXG43VMU5TKOJQGA3TQNJRGEYKC5QC> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[DecimalTurn]

Woah, 65MB! This is certainly pushing beyond TOML's original purpose of offering human readable config files.
Is there a reason why you chose TOML to store this data?

[AlbinoGeek]

I mean the options were basically JSON and YAML otherwise. And JSON is huge on disk for the same format while being almost unreadable, where YAML is wonderful for file size but harder for users to work with, given that it is indentation sensitive. TOML was both easier for users to parse and also convenient for machines (Bun.TOML etc.)

…

On Wed, Oct 21, 2026, 10:26 Martin Leduc ***@***.***> wrote: *DecimalTurn* left a comment (DecimalTurn/toml-patch#321) <#321 (comment)> Woah, 65MB! This is certainly pushing beyond TOML's original purpose of offering human readable config files. Is there a reason why you chose TOML to store this data? — Reply to this email directly, view it on GitHub <#321?email_source=notifications&email_token=AAOSNPI62QBQ7I33LMUQJXT5VDWWBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMZSGIZDKMBRHE3KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-6322250196>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOSNPIHK6D736DFI3FPB5D5VDWWBAVCNFSNUABFKJSXA33TNF2G64TZHM4TKNBSG44DEMBQHNEXG43VMU5TKOJQGA3TQNJRGEYKC5QC> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[DecimalTurn]

Totally agree for YAML. For JSON, the file size compared to TOML would be usually smaller based on what I've read, but this might depend on the level of nesting and the average length of your keys. But if TOML works in your case, why not!