Feature/cyclic topology - #9
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8ee7d1f9ea
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| BexEstablishedIdentity carried = Objects.requireNonNull( | ||
| semanticIdentity.carryExactIdentity( | ||
| exactId, | ||
| BexFrozenWriter.toFrozen(value)), |
There was a problem hiding this comment.
When a host implementation of carryExactIdentity throws an unexpected runtime exception, this exact-value branch lets it escape directly, whereas transient identity establishment passes the same kind of host failure through failureBoundary.preserveOrWrap. This exposes adapter exceptions such as IllegalStateException to callers instead of the documented BexException boundary; wrap this call using the same failure-policy handling as establishIdentity.
Useful? React with 👍 / 👎.
| require(blockers, | ||
| "candidate-source-lock".equals(baseline.get("status")), | ||
| "candidate-baseline-not-source-locked"); |
There was a problem hiding this comment.
Every invocation of the newly exposed bexSdkStageVerify task fails here regardless of the staged artifacts because its checked-in sdk-stage-language-baseline.json has status retired-after-publication, not candidate-source-lock. This contradicts the README's new claim that the task verifies the locked candidate repository; either make the lifecycle explicitly unavailable for a retired baseline or supply an active source-lock baseline when advertising the task.
Useful? React with 👍 / 👎.
| require(stagedRepositoryPath == null) { | ||
| "$requestedPublishedOnlyTask is published-only and forbids " + | ||
| "blueLanguageRepository" |
There was a problem hiding this comment.
When publish is invoked with bexSdkStagingRepository, PublicationConventionsPlugin makes each publish task depend on bexSdkStageVerify, and that gate requires -PblueLanguageRepository. This settings check rejects that required property for every task whose name starts with publish, so the separate candidate-publish flow cannot even configure; running verification first does not help because the publish graph executes the gate again. Exempt the explicitly staged SDK publication mode from this published-only rejection.
Useful? React with 👍 / 👎.
| const artifactHashes = reports.map( | ||
| (report) => report.dependency?.resolution?.artifact?.sha256 ?? 'missing' | ||
| ); |
There was a problem hiding this comment.
If the repository serves different focused module JARs to the four isolated builds while the aggregate blue-language-java JAR remains unchanged, this repeatability check still reports dependencyIdentityRepeated because it compares only resolution.artifact.sha256 for the aggregate. Each report already contains dependency.resolution.artifacts, so the complete name/hash set should be compared; otherwise the published-repeatability receipt can claim identical dependencies for builds that actually compiled and ran against different Language module bytes.
Useful? React with 👍 / 👎.
1 participant
Summary
Finalizes BEX exact-value and semantic-identity handling, and migrates the public release pipeline to the published Blue Language
3.1.0-rc.21artifacts.What changed
ProcessorExecutionContextinto BEX gas, identity, and output-admission boundaries.v3.1.0-rc.21at commit5c4e5c88fa75d6cbc52b2e8772f14f2ac5246f52.Verification
An exact tagged
v1.1.0-rc.4workflow simulation passed:releaseReady: trueworkingReady: truemodernizationReady: true