You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Breaking change - dropped explicit export of ServiceContextModule #251
Hi folks, looks like we may have caused a breaking change in v1.6.0 which drops explicit export of ServiceContextModule. Can we please continue supporting it until the next major version?
changed the title [-]Breaking change - dropped explicit import of `ServiceContextModule`[/-][+]Breaking change - dropped explicit export of `ServiceContextModule`[/+]on Oct 12, 2026
Thank you @williazz for the report and for opentelemetry-swift#1228 fix.
We do not plan to restore ServiceContextModule availability from this package.
OTelSwiftTracing does not explicitly depend on ServiceContextModule. SwiftPM exposes transitive modules to the compiler, so the import compiled while depending on swift-distributed-tracing 1.5.0, but SwiftPM does not promise this. There is a special compiler flag --explicit-target-dependency-import-check to check for this to be safe.
Unfortunately, it is impossible to create a new module in SDT with the old module name, as that name would collide with an older swift-service-context.
The names from import Tracing still work in 1.6.0 as deprecated typealiases.
The fix in #1228 is correct — drop the import and rely on import Tracing. A package that needs the old ServiceContextModule should depend on swift-service-context. SDT-0002 documents this under "Breaking changes". We also discussed this case in the SDT-0002 review thread.
Sorry about this, and thank you for the reports. @0xTim is right: removing the explicitly re-exportedServiceContextModule should not have been shipped in a minor release.
SDT gets a ServiceContextModule in the Instrumentation product. import ServiceContextModule works for packages that depend only on Tracing or Instrumentation.
SSC keeps its ServiceContextModule product, but its target gets a different name ServiceContextModuleCompatibility, because SwiftPM needs unique target names across the package graph. SSC also reexports ServiceContextModule from SDT.
Removes the deprecation of ServiceContext symbols so any warnings-as-errors do not trigger build failure. — UPD: this we decided to not to include during the review
For users explicitly depending on both packages, both packages should be updated together, if nothing is pinned, SwiftPM will handle it.
I've checked several packages (pre- and post- SDT 1.6.0 adoption, if it was already merged), seems to work, but would appreciate more eyes to avoid breaking more stuff.
Activity
[-]Breaking change - dropped explicit import of `ServiceContextModule`[/-][+]Breaking change - dropped explicit export of `ServiceContextModule`[/+]kukushechkin commentedon Oct 12, 2026
Thank you @williazz for the report and for opentelemetry-swift#1228 fix.
We do not plan to restore
ServiceContextModuleavailability from this package.OTelSwiftTracingdoes not explicitly depend onServiceContextModule. SwiftPM exposes transitive modules to the compiler, so the import compiled while depending on swift-distributed-tracing 1.5.0, but SwiftPM does not promise this. There is a special compiler flag--explicit-target-dependency-import-checkto check for this to be safe.Tracingstill work in 1.6.0 as deprecated typealiases.The fix in #1228 is correct — drop the import and rely on import
Tracing. A package that needs the oldServiceContextModuleshould depend on swift-service-context. SDT-0002 documents this under "Breaking changes". We also discussed this case in the SDT-0002 review thread.We will keep this Issue open so other can see it.
0xTim commentedon Oct 12, 2026
To be fair, with the
@_exportedthat was removed in https://github.com/apple/swift-distributed-tracing/pull/240/changes#diff-5c2efeffd3cbaf0bc282145eb3d633deb1b31f782f23d5929cf42222785f4071L16 - this is a major API break, the package opted into vendingServiceContextModuleas part of it's API. This isn't just SwiftPM's leaky imports so this should have only been done as a SerVer major and is not being a good ecosystem citizen by breaking like this. This has broken a lot of stuffwilliazz commentedon Oct 13, 2026
https://forums.swift.org/t/proposal-sdt-0002-move-servicecontext-from-ssc-to-sdt/89514/2
It's small potatoes at this point, but I wonder if the magnitude of impact was larger than anticipated during previous discussion?
kukushechkin commentedon Oct 13, 2026
Sorry about this, and thank you for the reports. @0xTim is right: removing the explicitly re-exported
ServiceContextModuleshould not have been shipped in a minor release.PRs that restore compatibility:
ServiceContextModuleto Swift Distributed Tracing #252ServiceContextModuletoServiceContextModuleCompatibilityswift-service-context#99What they do:
ServiceContextModulein theInstrumentationproduct.import ServiceContextModuleworks for packages that depend only onTracingorInstrumentation.ServiceContextModuleproduct, but its target gets a different nameServiceContextModuleCompatibility, because SwiftPM needs unique target names across the package graph. SSC also reexportsServiceContextModulefrom SDT.For users explicitly depending on both packages, both packages should be updated together, if nothing is pinned, SwiftPM will handle it.
I've checked several packages (pre- and post- SDT 1.6.0 adoption, if it was already merged), seems to work, but would appreciate more eyes to avoid breaking more stuff.
Add `ServiceContextModule` to Swift Distributed Tracing (#252)
kukushechkin commentedon Oct 13, 2026
swift-distributed-tracing 1.7.0 is tagged, this should now restore compatibility with
import ServiceContextModule. And the corresponding swift-service-context 1.5.0.williazz commentedon Oct 13, 2026
v1.7 mitigated the issue for us - thanks @kukushechkin
kukushechkin commentedon Oct 14, 2026
I would keep this opened for now so it is easier discoverable.