Summary
During the 0.1.1 accept-central verification, the iOS consumer project (sharingan-ios-consumer-test) hit a one-time build failure on the first --refresh-dependencies build that combined downloading the noop klib from Maven Central with the Kotlin/Native compile in the same invocation:
ERROR: .../caches/modules-2/files-2.1/io.github.mibrahimdev/sharingan-noop-iossimulatorarm64/0.1.1/.../sharingan-noop-iosSimulatorArm64Main-0.1.1.klib
e: java.lang.AssertionError: .../sharingan-noop-iosSimulatorArm64Main-0.1.1.klib
FAILURE: Build failed with an exception.
Why this is NOT a corrupt artifact
- A plain retry built SUCCESSFUL with no other changes.
- A full clean-room (Gradle module cache purge +
--refresh-dependencies) also built SUCCESSFUL.
- A corrupt Central klib would fail deterministically; this failed exactly once, on the first run that raced the download against the K/N compile.
The published io.github.mibrahimdev:sharingan-noop-iossimulatorarm64:0.1.1 artifact is verified good.
Suspected cause
A race in the Kotlin/Native toolchain between the dependency download completing and the compiler opening the klib within the same Gradle invocation — i.e. upstream K/N/Gradle tooling behavior, not something this library controls.
Why file it here
On record so that if a consumer reports the same first-build failure against 0.1.1, the answer is known: retry the build (or purge the module cache); the artifact is fine. If more reports come in with a reproducible pattern, escalate upstream to JetBrains (kotlinlang KT tracker) with the details.
Environment
- Kotlin 2.4.0, Gradle 8.13, macOS (Darwin 25.5.0), Xcode iOS simulator target
iosSimulatorArm64
- Observed 2026-07-03 during the 0.1.1 accept-central pass; details in
sharingan-ios-consumer-test/FEEDBACK.md section (H)
🤖 Generated with Claude Code
Summary
During the 0.1.1 accept-central verification, the iOS consumer project (
sharingan-ios-consumer-test) hit a one-time build failure on the first--refresh-dependenciesbuild that combined downloading the noop klib from Maven Central with the Kotlin/Native compile in the same invocation:Why this is NOT a corrupt artifact
--refresh-dependencies) also built SUCCESSFUL.The published
io.github.mibrahimdev:sharingan-noop-iossimulatorarm64:0.1.1artifact is verified good.Suspected cause
A race in the Kotlin/Native toolchain between the dependency download completing and the compiler opening the klib within the same Gradle invocation — i.e. upstream K/N/Gradle tooling behavior, not something this library controls.
Why file it here
On record so that if a consumer reports the same first-build failure against 0.1.1, the answer is known: retry the build (or purge the module cache); the artifact is fine. If more reports come in with a reproducible pattern, escalate upstream to JetBrains (kotlinlang KT tracker) with the details.
Environment
iosSimulatorArm64sharingan-ios-consumer-test/FEEDBACK.mdsection (H)🤖 Generated with Claude Code