perf(build): make Tokio features crate-owned - #1968
Merged
limityan merged 1 commit intoAug 2, 2026
Merged
Conversation
Move runtime capabilities from the workspace root to their consuming crates and feature owners. Keep bitfun-core no-default builds viable with fail-closed cleanup and metadata-backed dependency guardrails.
limityan
marked this pull request as ready for review
August 2, 2026 07:19
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
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.
Summary
tokio/fulland make each root-workspace crate select the runtime capabilities it actually ownsbitfun-services-integrationsfeaturebitfun-core --no-default-featuresviable, including fail-closed outbound-claim cleanup that retains its durable recovery recordArchitecture and scope
product-fullremains the compatibility product assembly boundary; it is not added to any direct dependency or widened to make checks pass.--lib, andremote_connect_host_boundarydeclaresservice-integrations, so unrelated product integration targets are not compiled for a no-default unit test.Measured dependency impact
bitfun-runtime-portsnormal unique package closurebitfun-runtime-portstest unique package closurebitfun-services-integrationsplugin-sourceall-target closureCold timings are directional local Windows measurements; package-closure counts are the stable dependency evidence.
Validation
node --test scripts/check-core-boundaries.test.mjs? 32/32 passedbitfun-services-integrationsfeatures checked independently with--no-default-features --libcargo check -p bitfun-core --no-default-featurescargo check --workspace --quietcargo metadata --locked --no-deps --format-version 1The workspace check reports only pre-existing CLI unused-code/import warnings.
Follow-up kept explicit
bitfun-core's standaloneservice-integrationsandssh-remotefeature profiles are not yet fully closed. This PR deliberately does not mask that work by attachingproduct-full; the next dependency-boundary PR will resolve those owner relationships directly.