Preserve comments across web UI config edits #88
No reviewers
Labels
No labels
Bug
BuildIssue
Claude-fixed
Enhancement
In Progress
Low priority
On Hold
Rejected
Security
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
keyop-go/nfq_forwarder!88
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "issue34_preserve_comments"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #34.
See the issue comment for the full design writeup. Summary:
config.MergeIntoYAML(baseYAML, newConfig)(internal/config/comments.go): marshalsnewConfigthe ordinary way into a comment-free tree, then splicesbaseYAML's comments onto the matching nodes via yaml.v3'syaml.Node. Sequence items (connections,defaults.by_network,forwarded_ports) are matched by natural identity, not position, so a reorder in the structured form moves the comment with it rather than stranding it. A removed item's comment is dropped, not reattached to some unrelated neighbor. Falls back to a plain marshal if the base doesn't parse.configEditRequestgainsbase_yaml, sent by the client alongside every structured-form submission;config_edit.js'sstategainsbaseYAML, updated from every raw/validate/save response so comments survive arbitrarily many mode toggles within a session, not just a single save.HeadCommenton the key node, an inline comment inLineCommenton the value node, and a sequence-item preamble inHeadCommenton the item node itself, which is already exactly the preamble-block convention you suggested.internal/configstays effectively 100% covered - the only gaps areyaml.Marshalerror branches on a fixed-shape Go struct, which can't realistically fail. NewTestAPIConfigSaveStructuredFormPreservesCommentsis the end-to-end regression test through the real HTTP handlers.make lint/make testclean.Separately: while checking test coverage I hit an unrelated stale git stash (
WIP on main: cb8f04b Merge branch 'issue27_toolchain_versioning') that conflicted onMakefile- resolved by keeping the current Makefile (confirmed identical to HEAD after). I did not drop the stash entry itself - it's superseded/obsolete scratch from mid-development of issues #26/#36 (both already merged in a different final form), but I did not want to delete it without your say. Let me know if you'd like me to drop it or if you want to look at it first.All makes sense and appears to work in testing.