gate: pin the module-identity chain (9 repos) - #101
Draft
dlipicar wants to merge 4 commits into
Draft
Conversation
Pins the five identity PRs plus the two catch-up inputs they require: logos-lidl dd34401 #10 the derived-identity pass logos-protocol 40180d1 #61 proxy fallback + listing logos-cpp-sdk 1e516c0 #141 cdylib dispatch + consumer wrappers logos-qt-sdk 9e5ddf1 #35 Qt consumer wrappers logos-rust-sdk 8425301 #43 Rust provider + consumer logos-module-builder 378bdba catch-up, see below logos-plugin-qt 9b2c64e catch-up, see below WHY THE TWO CATCH-UP PINS. Each identity PR is branched off its repo's master, and qt-sdk master has already removed `--backend cdylib` from logos-qt-generator (it moved to logos-qt-host-generator in logos-plugin-qt). The module-builder this branch pinned still calls the removed flag, so pinning qt-sdk without pinning module-builder fails every universal module build with "--backend cdylib was removed". plugin-qt then has to come along because protocol master's TokenManager::forIdentity is what its master needs. WHY THIS IS ON feat/sdk-codegen-phase-a AND NOT master. Workspace master pins logos-nix e637a1f (March), which predates lib.forAllTargets; every repo master here now needs it, so the same pins do not even EVALUATE on master. phase-a already carries logos-nix 6e0f4a7, which has it. That is the empirical answer to "which branch carries the gate". NOT MERGEABLE AS IS, and the reason is pre-existing rather than anything in the identity work. module-builder master refuses a core module that declares no `interface` -- "NO glue would be generated and every call into it would fail at runtime rather than at build time" -- and logos-test-modules still ships six: dummy_module_000000, test_basic_module, test_extlib_module, test_fullapi_qtproxy, test_ipc_module, test_ipc_new_api_module Those need migrating to interface "universal" (or "cdylib") before this gate can go green. That is the SDK-stack reconciliation, not this feature. VERIFIED GREEN on these pins: test_basic_module_cpp and test_interface_module_cpp both build, the latter emitting a consumer wrapper carrying name()/version(). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The 2026-08-20 merge wave migrated the last interface-less core modules to
interface "universal": logos-test-modules 626fbaa and logos-capability-module
c670f7f. That clears what blocked this gate -- module-builder master refuses a
core module declaring no `interface`, and both of those repos had some.
Both pins are REQUIRED, not opportunistic. A stale one fails at BUILD time with
module-builder's rejection, never at eval, so neither shows up by reading the
flake -- capability_module was found only by building it and watching the old
pin fail exactly as predicted.
Sweep over all 21 logos-test-modules targets on these pins: 18 pass. The two
failures reproduce with this branch's logos-qt-sdk swapped for plain
origin/master, so they are logos-test-modules-master vs logos-qt-sdk-master
skew, not the identity work:
test_fullapi_ext_cpp echoOptional: an optional RETURN (`-> ?T`) is not
supported -- needs `-> result`, or the check needs to
admit it
test_qml_backend no member named 'add' in 'TestBasicModule' -- the
consumer wrapper generated from the newly-migrated
test_basic_module contract no longer carries add()
Both would meet any repin of this workspace onto current masters, independently
of this chain.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
dlipicar
changed the title
The lidl-gen round-trip spec asserted the provider backend emits '9 methods'; it is 11 with the derived identity methods. logos-rust-sdk eb46a2f. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
logos-lidl#10 landed as ae3ffe0 and logos-protocol#61 as 43cd059, so the gate tracks their masters instead of the PR branches. cpp-sdk, qt-sdk and rust-sdk move with their re-pointed locks. The lidl narHash is unchanged across the merge (sha256-WHmisUvYA8DQ2ZxSF2mM2...), so the merged tree is byte-identical to the branch everything here was built and tested against. Remaining in the chain: logos-cpp-sdk#141, logos-qt-sdk#35, logos-rust-sdk#43. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Integration gate for the module-identity chain — every module exposes
name()andversion(), autogenerated from its metadata.The chain
dd3440140180d11e516c09e5ddf1eb46a2f378bdba9b2c64e626fbaac670f7flogos-protocol is independent of the other four and can merge on its own.
Why four catch-up pins
Each identity PR is branched off its repo's master, and qt-sdk master has removed
--backend cdylibfromlogos-qt-generator(it moved tologos-qt-host-generatorin logos-plugin-qt). The module-builder this branch pinned still calls the removed flag, so pinning qt-sdk without module-builder fails every universal module build. plugin-qt follows because its master needsTokenManager::forIdentity, which arrived in protocol master.module-builder master then refuses a core module declaring no
interface— and both logos-test-modules and logos-capability-module had some until the 2026-08-20 merge wave migrated them. Both pins are required, not opportunistic: a stale one fails at build time with that rejection and never at eval, so neither is visible by reading the flake.Why this targets
feat/sdk-codegen-phase-aand notmasterWorkspace master pins
logos-nixe637a1f(March), which predateslib.forAllTargets. Every repo master in this chain needs it, so these pins do not even evaluate on master. phase-a carrieslogos-nix6e0f4a7, which has it. Not a preference — master cannot hold these pins.Status: 18 of 21 test-module targets build
All three failures were checked against a control with all five identity repos swapped for their plain masters. Every one reproduces, so none is caused by this chain:
test_fullapi_ext_cppechoOptional: an optional RETURN (-> ?T) is not supportedtest_qml_backendno member named 'add' in 'TestBasicModule'tests(the suite).resultwhilestatusisokThe third is the one worth attention:
status: okwith an empty result points at the result-serialization path in the call envelope rather than at dispatch. It could not be bisected further by downgrading logos-protocol, because plugin-qt master needsTokenManager::forIdentityfrom protocol master — the two move together.Any repin of this workspace onto current masters meets all three, independently of this chain. Draft for that reason: the reds are upstream, and this gate is what makes them visible.
Verified
test_basic_module(previously blocked by the interface-less rejection),test_basic_module_cpp,test_interface_module_cppand 15 others build on these pins, with consumer wrappers carryingQString name(...)/QString version(...).🤖 Generated with Claude Code