Candidates with no compiler artifact cannot be expressed after #242

[thedavidmeister]

What

#242 removed DeployCandidate.sourceCreationCode and made
checkCandidatesAnchoredToSource read the source operand from
vm.getCode(candidate.snapshot.artifactPath). That assumes every candidate's
source is a compiler artifact resolvable by artifact id.

Two candidates across the org are not, and cannot be expressed at all under the
new shape. The anchor loops over EVERY candidate and there is deliberately no
way to spell an exemption, so for these two vm.getCode has nothing to resolve
and the check fails — inside RainDeployBroadcast.run(), before the broadcast,
not only in CI. script/Build.sol's regenerateSnapshots is blocked
identically, since #242 changes it to write from the same call.

The two

raindex, suite route-processor —
src/abstract/RaindexDeploySuites.sol:

artifactPath: "RouteProcessor4",
sourceCreationCode: ROUTE_PROCESSOR_4_CREATION_CODE

There is no local Solidity source. The creation code is a pinned hex literal in
src/lib/deploy/LibRouteProcessor4CreationCode.sol, taken from sushiswap's
published deployment. The artifactPath is a bare name rather than
<path>:<Name>, and raindex/test/script/Build.t.sol:148 documents that bare
form as the convention for a suite with no local source.

rain.math.float.deploy, suite log-tables —
src/abstract/DecimalFloatDeploySuites.sol:

artifactPath: "",
sourceCreationCode: LibDataContract.contractCreationCode(LibDecimalFloatDeploy.combinedTables())

A data contract assembled from generated pointer tables. There is no source
file, and artifactPath is empty.

Why this is the fix's problem rather than the consumers'

Both are legitimate deploy candidates. A vendored third-party deployment and a
generated data contract are exactly the cases where a snapshot's pins matter
most, because no local type(X).creationCode exists to fall back on. #242's
premise — that naming the contract and letting the compiler answer removes the
consumer's ability to supply both operands — holds only where a compiler
artifact exists. Where none does, the consumer must supply the source bytes, and
the design has nowhere to put them.

This was not visible from rain.deploy alone: its own candidates are all
ordinary contracts.

Status

#242 is merged to main but not released, so no consumer is broken yet. A
rain-deploy release that carries #242 as it stands makes these two repos
unable to build or broadcast their affected suites.

Directions (for triage, not a recommendation)

• Let a candidate carry explicit source bytes again for the artifact-less case,
  with the anchor preferring vm.getCode when an artifact id resolves — which
  reintroduces the test(fork): split the tests that need a chain from the ones that do not #34 hazard for exactly those candidates, so it needs a reason
  why that is acceptable there and not generally.
• Give the artifact-less case its own type, so it is visibly a different thing
  rather than an exemption spelled inside the ordinary one.
• Have vm.getCode resolve these by teaching the build to emit an artifact for
  a vendored or assembled creation code, so the anchor's premise becomes true
  rather than being worked around.

Provenance

Found while filing the #242 consumer migration issues
(#243). Verified against both repos' source on their
default branches, not inferred from the migration text.