comsys.db in 2.13

[Kristian Hansen]

Hi all,

I think perhaps I've discovered a potential issue with the comsys in 2.13.

As stated in the release announcement,  "SQLite is now the always-on storage backend. All object metadata,
   attributes, comsys channels, and @mail are stored in a single SQLite
   database with write-through on every mutation."

But I just found that created comsys channels did not persist following a @restart and the log appears to show TinyMUX was still looking for the old style comsys.db:

- "Error: Couldn’t find data/comsys.db."

This is in version  2.13.0.14 [2026-MAY-01]

Channels did not persist even after explicit @backup and the same result was observed using both @restart and @shutdown.

It's entirely possible of course that I've missed something in config or the release notes, so if so, apologies!

Bests,

/<

[Brazil]

Hi Kristian,

Good catch — and no, you didn't miss anything in config. This is a real bug, and you diagnosed it correctly. The good news is it's already found and fixed in the development tree.

What's happening: the SQLite comsys loader is gated on an internal has_comsys metadata flag. Channel changes (like @ccreate) do write through to the SQLite tables correctly, but in 2.13.0.14 that gate flag was only ever set by the offline DbConvert -C import path. So on a game that was started fresh on SQLite (never imported via -C), your channels were genuinely being written to the database — but on the next @restart/@shutdown the loader saw no gate, ignored the rows, and fell back to looking for the old flatfile data/comsys.db. Hence the "Couldn't find data/comsys.db" in your log, with the channels seemingly vanishing while the rows sat orphaned in the DB the whole time. @mail had the identical issue.

The fix makes the write-throughs maintain the gate themselves, so anything created in-game now warm-loads in a fresh process. It's committed on master (commit 9dfa2c40, "engine: comsys/mail created in-game now survive a warm boot") and will be in the next release.

If you want to recover the channels you already created before upgrading: they should still be in your SQLite database as orphaned rows. Once you're on a build with the fix, they should load on the next boot without you having to recreate them — let me know if they don't and I'll help you dig them out.

Thanks for the clear report!

Best,
Brazil

[Kristian Hansen]

Hi Brazil,

Thanks for the info - I'll wait until the next release to recover the channels. 

While we're on the subject of the comsys, I was wondering about the behaviour of sending a message to a channel, either using the alias or with @cemit. It seems that only literal messages can be sent, or if there is a way to send strings containing evaluated u() calls to a channel then I haven't figured it out. I have assumed it's intentional for reasons of security or spoofing, but would love to know for sure if it's intentional, as I have a use case where handler objects could post system management and debug information to a (private) channel for the developers and staff to see.

Any insight would be much appreciated!

Bests,
/<

--

---
You received this message because you are subscribed to the Google Groups "tinymux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tinymux+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/tinymux/a476dc7a-c4a1-4711-9608-4e7825425d8bn%40googlegroups.com.

[Brazil]

Hi Kristian,

The short version: channel chat is deliberately literal when you type it directly. Both the channel alias (<alias> message) and a hand-typed @cemit chan=message send the text exactly as written — no u() calls, functions, or %-substitutions are evaluated. That's by design, so that ordinary chat containing brackets, percent signs, or function-looking text appears as-is instead of being surprisingly evaluated (or used to spoof).

The escape hatch is that @cemit does evaluate its message when it's run from softcode rather than typed live at the keyboard. So for your use case — handler objects posting system/debug info to a private channel — it works with no special effort, because those objects are running @cemit from their own code:

  &do_report obj=@cemit staff=Load: [u(obj/gather_stats)] at [time()]
  $+report:@trigger me/do_report

When do_report fires, the [u(...)] and [time()] are evaluated and the finished line goes out to the channel.

If you want to confirm it for yourself from the command line, this one-liner forces the @cemit through the queue (which is what makes it evaluate):

  @force me=@cemit staff=2+2 is [add(2,2)]

You should see 2+2 is 4 on the channel — versus the literal text if you'd typed the same @cemit directly.

So nothing's broken; you just need the @cemit to originate from softcode, which your handler objects already do. Hope that unblocks you — shout if the evaluation isn't behaving the way you expect once you wire it up.

Bests,
Brazil

[Kristian Hansen]

Great, thanks! I've parked the channel work for the time being, I'll let you know if I'm not able to get it working once I'm on a new version.

Much appreciated!

Bests,
/<