Known 1.0.2 limitation: setup stays latched when the first open fails before load step 7 (e.g. an incompatible artifact)

Known 1.0.2 limitation: setup stays latched when the first open fails BEFORE load step 7. For example, an artifact that will not load. A different setup is then refused until the process restarts.

Reported (measured by a downstream consumer on go/v1.0.2, in fresh processes, on the real artifact):

A refused zone is fixed in 1.0.2 (Known 1.0 limitation: setup latches an image zone the library does not know; the process cannot recover without a restart #458): Setup("Not/AZone"), then the open fails with code 36, then Setup("UTC") is accepted, and the next open works.
A failed load is not: under Setup("Asia/Tokyo"), the first open fails with CHTYPES_ARTIFACT_INCOMPATIBLE, before any library reached step 7. A later Setup("UTC") is still a UsageError.

Why (read from source, consistent with the report):

The Known 1.0 limitation: setup latches an image zone the library does not know; the process cannot recover without a restart #458 fix clears the setup record only when step 7 itself fails (chs_initialize or chs_set_defaults).
A failure in an earlier load step leaves the record as it was: a fetch, a signature check, an incompatible artifact, a missing symbol. Yet no library has taken that setup.
All four bindings wrap only step 7 this way (inferred from the code; only Go was measured). So all four behave alike, and "the four bindings give one answer" holds.

Options:

Setup is replaceable until the first library completes step 7. Any setup call before then replaces the record; after it, today's rule holds.
- This is "latch only on success", taken literally. It covers this case and the Known 1.0 limitation: setup latches an image zone the library does not know; the process cannot recover without a restart #458 case with one rule, and removes the step-7 special case.
- It costs the "first setup stands" refusal between two callers that disagree before the first successful open. Once a library is set up, that refusal stays.
Clear the record on ANY failed open while no library has completed step 7. This fixes this case too, but keeps rule 1 for a second setup before any open is attempted.
Keep it, and list it as a known 1.0 limitation.

Options 1 and 2 are binding-only, a 1.0.x patch in all four with one shared case, like #458. The decision is the maintainers'. This issue tracks it.

🤖 Generated with Claude Code

Decided: option 2. It ships in the next 1.0.x release of all four bindings, with whatever else is ready. There is no release just for this.

The rule:

While no library has completed load step 7, ANY failed open clears the setup record, whatever the failure: fetch, verification, an incompatible artifact, a missing symbol, or step 7 itself. The next setup is then accepted.
Once one library has completed step 7, today's rule holds: the same setup is a no-op, and a different one is a UsageError naming both.
A second, different setup before any open is attempted is still a UsageError, never a silent last-wins. Two components that disagree before any open keep that protection.

The change:

one shared case covering a failure before step 7 and a failure in step 7, passing in all four bindings;
docs/reference/bindings-v1.md §6 updated to match.

Until then: fix the artifact, then call setup again with the SAME setup. A same-spelling setup is a no-op and is accepted, and the next open uses it.

🤖 Generated with Claude Code

setup: any failed open before the first step 7 clears setup (#468)

Refined before merge: "unlock", not "clear". Taken literally, "clear" would have failed open. After a transient failure, a plain retry with no new setup would silently load under the empty setup (UTC) instead of the zone the caller chose. That is worse than the original bug.

The rule that ships:

After a failed open, while no library has completed load step 7, the setup record is KEPT but becomes replaceable.
- A retry with no new setup uses the recorded zone and defaults, never UTC by default.
- A different setup is accepted, and replaces the record.
Two different setup calls before any open is attempted are still a UsageError.
A caller's own misuse that fails before any load is attempted unlocks nothing. Examples: a refused version spelling, or an unverified open without its opt-ins. Only an open that actually attempted a load and failed unlocks: fetch, verification, an incompatible artifact, a missing symbol, or step 7.
After the first successful step 7, today's rule holds.

The shared case gains two paths:

a transient failure, then a plain retry, which must load under the recorded zone;
a refused spelling, which must leave the record locked.

🤖 Generated with Claude Code

setup cases: a failed open unlocks, never clears (fails on the clear …

setup cases: the Rust runner runs every case before its verdict

setup: a failed open unlocks the setup, it never clears it (#468)

Merge pull request #469 from Wave-RF/v1-setup-latch-468

Fixed on v1 (#469). It ships in the next 1.0.x release of all four bindings, and this issue closes then.

The shared case now covers each path, in all four bindings:

a load refused before step 7, after which a corrected setup is accepted;
a failed open followed by a plain retry, which loads under the RECORDED zone. The test reads back the zone the library itself committed, not just "no error";
a refused version spelling, after which a different setup is still refused;
a replaced setup, which is locked again.

Each path failed on the earlier code and passes now. The rule is docs/reference/bindings-v1.md §6 rule 4.

🤖 Generated with Claude Code

test(typelayer): pin that a later tenant in a zone chtypes cannot loa…

Done on v2 (checked 2026-10-09). The fix (#469) is in, and the setup-latch cases are in the shared v2 fixtures (tests/fixtures/abi-v2/setup-cases.json). All four bindings run them (Go setup_cases_test.go, Python test_public_setup_cases.py, TS setup-cases.test.ts, Rust api_v1_setup_cases.rs).

Navigation Menu

Repository navigation

Known 1.0.2 limitation: setup stays latched when the first open fails before load step 7 (e.g. an incompatible artifact) #468

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Known 1.0.2 limitation: setup stays latched when the first open fails before load step 7 (e.g. an incompatible artifact) #468

Description

Activity

EricAndrechek commented on Oct 6, 2026

EricAndrechek commented on Oct 6, 2026

EricAndrechek commented on Oct 6, 2026

EricAndrechek commented on Oct 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions