Open question: could error/init.lua's uuid dependency be made lazy to break the error->uuid->fs->sys cycle? #52

New issue

Open

opened 2026-08-15 21:59:59 +02:00 by michael · 0 comments

michael commented

2026-08-15 21:59:59 +02:00

Owner

Background

During the #50 error-handling pass, the error -> uuid -> fs.handle -> fs.dir -> sys load-time cycle (deferred require("daw.common.error")
in sys.lua, fs/dir.lua, fs/handle.lua, uuid.lua) was
rediscovered and investigated from scratch, including a git log
search to confirm it was deliberately introduced in the
daw_error/v1 migration (commit 51cab24, 2026-08-06), not an
accident. It was left completely untouched -- only the fallback
value at the "daw.common.error itself unavailable" boundary changed
(plain string -> the daw-error-facility-unavailable sentinel from
DAW/daw-contracts#11).

The cycle and the reasoning behind it are now documented in
docs/error.md, docs/fs.md, docs/sys.md, and docs/common-uuid.md.

Open question (not decided)

Mid-session, a possible way to break the cycle entirely was proposed:
error/init.lua only uses daw.common.uuid for a quality-of-id
upgrade (a real UUID v4 instead of its own local fallback_id()), not
structurally -- it already tolerates uuid being unavailable. Making
that require("daw.common.uuid") lazy (deferred to call time, inside
M.new(), the same pattern already used elsewhere for
daw.common.error) would remove the one eager edge that closes the
loop.

This was explicitly not decided -- the session was paused before
evaluating it further, specifically to avoid further architecture
churn on the same afternoon.

Goal

Hold this open question so it can be picked up deliberately in a
future session, instead of being rediscovered/re-investigated from
scratch again (as happened this session).

Scope

No code change is decided or requested by this issue. When revisited,
evaluate:

whether deferring error/init.lua's require("daw.common.uuid")
to call time is worth doing (removes the cycle vs. keeps working
code unchanged);
if yes, implement consistently with the existing deferred-require
pattern in sys.lua/fs/dir.lua/fs/handle.lua/uuid.lua;
if no, close this issue with that explicit decision recorded.

Acceptance criteria

A decision (proceed or explicitly reject) is recorded here
whenever this is revisited.
If accepted: error/init.lua's uuid dependency is deferred,
the cycle is broken, and docs/error.md/docs/fs.md/
docs/sys.md/docs/common-uuid.md are updated accordingly.
If rejected: this issue is closed with the reasoning recorded,
so the question doesn't get re-investigated from scratch again.

DAW/daw-contracts#11
DAW/daw-docs#26
DAW/daw-lua-common#50

## Background During the `#50` error-handling pass, the `error -> uuid -> fs.handle -> fs.dir -> sys` load-time cycle (deferred `require("daw.common.error")` in `sys.lua`, `fs/dir.lua`, `fs/handle.lua`, `uuid.lua`) was rediscovered and investigated from scratch, including a `git log` search to confirm it was deliberately introduced in the `daw_error/v1` migration (commit `51cab24`, 2026-08-06), not an accident. It was left completely untouched -- only the fallback value at the "daw.common.error itself unavailable" boundary changed (plain string -> the `daw-error-facility-unavailable` sentinel from `DAW/daw-contracts#11`). The cycle and the reasoning behind it are now documented in `docs/error.md`, `docs/fs.md`, `docs/sys.md`, and `docs/common-uuid.md`. ## Open question (not decided) Mid-session, a possible way to break the cycle entirely was proposed: `error/init.lua` only uses `daw.common.uuid` for a quality-of-id upgrade (a real UUID v4 instead of its own local `fallback_id()`), not structurally -- it already tolerates `uuid` being unavailable. Making that `require("daw.common.uuid")` lazy (deferred to call time, inside `M.new()`, the same pattern already used elsewhere for `daw.common.error`) would remove the one eager edge that closes the loop. This was explicitly **not decided** -- the session was paused before evaluating it further, specifically to avoid further architecture churn on the same afternoon. ## Goal Hold this open question so it can be picked up deliberately in a future session, instead of being rediscovered/re-investigated from scratch again (as happened this session). ## Scope No code change is decided or requested by this issue. When revisited, evaluate: - whether deferring `error/init.lua`'s `require("daw.common.uuid")` to call time is worth doing (removes the cycle vs. keeps working code unchanged); - if yes, implement consistently with the existing deferred-require pattern in `sys.lua`/`fs/dir.lua`/`fs/handle.lua`/`uuid.lua`; - if no, close this issue with that explicit decision recorded. ## Acceptance criteria - [ ] A decision (proceed or explicitly reject) is recorded here whenever this is revisited. - [ ] If accepted: `error/init.lua`'s `uuid` dependency is deferred, the cycle is broken, and `docs/error.md`/`docs/fs.md`/ `docs/sys.md`/`docs/common-uuid.md` are updated accordingly. - [ ] If rejected: this issue is closed with the reasoning recorded, so the question doesn't get re-investigated from scratch again. ## Related - `DAW/daw-contracts#11` - `DAW/daw-docs#26` - `DAW/daw-lua-common#50`

michael added the

labels

2026-08-15 21:59:59 +02:00