Describe the bug
When a deployment plan is loaded from YAML via load_deployment / DeploymentSpecification::from_config_file, the ContractPublishSpecification::from_specifications method re-reads the .clar source from disk. This source is never passed through remove_env_simnet, so #[env(simnet)] code is included in the returned ContractPublishSpecification.source.
The existing deployment.remove_env_simnet() method (DeploymentSpecification::remove_env_simnet in types.rs) only strips simnet code from EmulatedContractPublish transactions and the contracts map — it does not handle ContractPublish transactions, which are used for devnet, testnet, and mainnet deployments.
This means that when a devnet/testnet/mainnet deployment plan is loaded from an existing YAML file (rather than freshly generated), the #[env(simnet)] code will be present in the contract source that gets deployed on-chain.
This was identified during review of PR #2340, which fixed the fresh-generation path but not the load-from-YAML path.
Affected code
ContractPublishSpecification::from_specifications in components/clarinet-deployments/src/types.rs (line ~611) — reads source from disk without stripping
DeploymentSpecification::remove_env_simnet in components/clarinet-deployments/src/types.rs (line ~1262) — only handles EmulatedContractPublish, not ContractPublish
To Reproduce
- Create a project with a contract containing
#[env(simnet)] code
- Run
clarinet devnet start once (generates deployments/default.devnet-plan.yaml correctly)
- Run
clarinet devnet start again with --use-on-disk-deployment-plan
- The deployment loaded from the YAML will contain the
#[env(simnet)] code in the contract source
Expected behavior
Loading a deployment from YAML for a non-simnet network should strip #[env(simnet)] code from ContractPublish transaction sources, the same way fresh generation does after PR #2340.
Describe the bug
When a deployment plan is loaded from YAML via
load_deployment/DeploymentSpecification::from_config_file, theContractPublishSpecification::from_specificationsmethod re-reads the.clarsource from disk. This source is never passed throughremove_env_simnet, so#[env(simnet)]code is included in the returnedContractPublishSpecification.source.The existing
deployment.remove_env_simnet()method (DeploymentSpecification::remove_env_simnetintypes.rs) only strips simnet code fromEmulatedContractPublishtransactions and thecontractsmap — it does not handleContractPublishtransactions, which are used for devnet, testnet, and mainnet deployments.This means that when a devnet/testnet/mainnet deployment plan is loaded from an existing YAML file (rather than freshly generated), the
#[env(simnet)]code will be present in the contract source that gets deployed on-chain.This was identified during review of PR #2340, which fixed the fresh-generation path but not the load-from-YAML path.
Affected code
ContractPublishSpecification::from_specificationsincomponents/clarinet-deployments/src/types.rs(line ~611) — reads source from disk without strippingDeploymentSpecification::remove_env_simnetincomponents/clarinet-deployments/src/types.rs(line ~1262) — only handlesEmulatedContractPublish, notContractPublishTo Reproduce
#[env(simnet)]codeclarinet devnet startonce (generatesdeployments/default.devnet-plan.yamlcorrectly)clarinet devnet startagain with--use-on-disk-deployment-plan#[env(simnet)]code in the contract sourceExpected behavior
Loading a deployment from YAML for a non-simnet network should strip
#[env(simnet)]code fromContractPublishtransaction sources, the same way fresh generation does after PR #2340.