Skip to content

fix(frontend): parse service configs with a spec-compliant TOML library - #122

Merged
dakejahl merged 1 commit into
mainfrom
fix/toml-editor-parser
Oct 23, 2026
Merged

dakejahl merged 1 commit into
mainfrom
fix/toml-editor-parser

Conversation

@dakejahl

Copy link
Copy Markdown
Contributor

Summary

The config editor on the Services page used toml-js 0.0.8. That parser corrupts configs when they're saved. This PR replaces it with smol-toml, a TOML 1.0 parser. The change is three lines in TomlEditor.vue plus the dependency swap.

What toml-js got wrong

Input toml-js Effect
email = "ops team@example.com" strips all whitespace on the line The value saves back as "opsteam@example.com".
api_key = "abc#123" cuts the line at the first #, even inside quotes The file no longer parses, and the editor opens with an empty form.
A comment line right after a [table] header treats the comment as the end of the table The keys after the comment become top-level keys.

The third row affects a shipped config. In the UI on main, opening the logloader editor and pressing Save without changing anything deletes [data], [download] and [upload] and moves their keys to the top level:

connection_url = "udp://:14551"
log_level = "info"
directory = "/var/lib/ark-os/logs/"
auto = true
latest_on_first_start = true
max_auto_queue = 5
remote_directory = ""
use_burst = true
api_key = ""

[api]
...

logloader reads those keys only inside their sections, so after that save it falls back to its built-in defaults. Its data directory moves to ~/.local/share/ark/logloader/ under the service user's home instead of /var/lib/ark-os/logs/. Changes the operator makes to the download settings, or to the remote api_key, have no effect.

Testing

I tested with the x86 harness (test/), driving headless Chrome through the real Services page:

  • main: reproduced the logloader save above.
  • This branch, Save with no changes: the values in logloader.toml are identical to the shipped file, and every section renders with its own fields.
  • This branch, values with special characters: I typed ops team@example.com and k3y#with spaces "q" into upload_remote.email and upload_remote.api_key, saved, reopened, and saved again. Both values were saved and read back exactly.
  • Other editors: dds-agent, rtsp-server, pointperfect and an add-on config render the same fields and input types as on main, including the _options dropdowns and dds-agent's conditional fields. No console errors.
  • Round trip of every config: each file in packaging/config/*.toml keeps its values through smol-toml's parse → stringify. The output also loads with Python toml 0.10.2, which merge_configs.py uses on upgrade.
  • vue-cli-service lint passes, and vue-cli-service build succeeds.

Not changed

  • Saving still rewrites the whole file, so comments are still dropped. That was already the case with toml-js.
  • The two parsers stringify numbers the same way: a whole-number float such as 1.0 is saved as 1. So this isn't a regression, and none of the shipped configs has a float.

🤖 Generated with Claude Code

The Services page's config editor used toml-js 0.0.8, which corrupts
configs on save:

- it strips all whitespace from every line before parsing, so string
  values lose their spaces ("ops team@x" saves back as "opsteam@x");
- it cuts each line at the first '#', even inside a string, so a value
  containing '#' no longer parses and the editor opens empty;
- a comment line after a [table] header ends the table, so the keys that
  follow are read as top-level keys. With the shipped logloader.toml,
  opening the editor and pressing Save without changing anything drops
  [data], [download] and [upload] and moves their keys to the top level,
  where logloader does not read them: it falls back to its defaults,
  including a data directory under the service user's home.

Switch to smol-toml (TOML 1.0), which parses all of these correctly and
whose output python's toml (merge_configs.py) and the services read.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
dakejahl added a commit that referenced this pull request Oct 23, 2026
The web UI can control any service that has a manifest, so an add-on
needs no polkit rule (or sudoers entry) of its own. Remove the example's
rule and the README's polkit section, and say that the manifest is what
lets the web UI control the service.

Also drop the caveat about the config editor stripping whitespace from
strings; #122 fixes the parser.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@dakejahl
dakejahl merged commit 5bd0ccb into main Oct 23, 2026
4 checks passed
@dakejahl
dakejahl deleted the fix/toml-editor-parser branch October 23, 2026 14:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant