mirror of
https://github.com/brazilofmux/tinymux
synced 2026-08-13 00:23:11 -04:00
4d3a85c536
Stage 2 moves the last piece of engine-owned channel state out of attributes. LOG_TIMESTAMPS becomes a column on the channel row (schema v15, seeded from the attribute by the same "non-empty is on" rule both implementations settled on in #1604). This is what closes #1585 rather than working around it. As an attribute the engine wrote the flag as GOD with AF_CONST, and bCanSetAttr denies AF_CONST in every branch including God's -- so the module's permission-checked write was refused and a channel whose timestamps the engine had turned on could never be turned off from the other side. A column has no permission bits to refuse with, so the whole class goes away. What deliberately does NOT move: MOGRIFY`* and CHATFORMAT. Those are game-authored softcode, not server configuration, and attributes are exactly the right home for them. The line stage 2 draws is ownership -- engine-owned config becomes columns; code the game wrote stays where the game can edit it. The attribute is left in place, inert, on the same reasoning as HISTORY_%d: a wrong migration should be recoverable rather than terminal. ok 1 - engine enables timestamp logging ok 2 - engine records retention on the channel row ok 3 - module reads the retention the engine set ok 4 - module reads history the engine wrote ok 5 - engine reads history the module wrote ok 6 - both implementations' messages, in order ok 7 - module keeps writing past the point the ring would wrap ok 8 - retention expires the oldest entries ok 9 - cmsgs() reports the retained count, matching retention ok 10 - timestamps the engine enabled apply under the module ok 11 - module can clear a flag the engine set (#1585) ok 12 - engine sees the flag the module cleared === comsys handoff: 12 passed, 0 failed, 0 known-failing === No TODO markers remain in that file. Cases 11 and 12 were the last one. Two things this turned up, both the same shape and both caught by the fixture rather than by reading: - The module's @cset/timestamp_logs gate asked whether the MAX_LOG ATTRIBUTE existed. Nothing writes it since stage 1, so the gate rejected every channel configured after the migration and the command silently stopped working. The engine had the identical gate and the identical failure, fixed the same way. Moving a value out of a store means finding every reader, and "does this attribute exist" is a reader that does not look like one. - The driver's own assertions had to move from get(HObj/LOG_TIMESTAMPS) to recall output. Reading the attribute would have tested storage that no longer decides anything, and would have kept passing after the flag stopped mattering -- the failure mode where a test outlives the thing it inspects. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| alarm | ||
| color_ops | ||
| comsys_handoff | ||
| comsys_history | ||
| config | ||
| db | ||
| dbt | ||
| format | ||
| libmux | ||
| luajit | ||
| narrowing | ||
| netaddr | ||
| nls | ||
| parity213 | ||
| scenario | ||
| stress | ||
| build-msvc.sh | ||