(ai-generated)
Summary
When a component's CVL generation fails in the greenfield natspec pipeline, nothing about it is
written to disk. The output directory holds the specs that succeeded and gives no sign that a
component is missing, so a run that lost a component looks exactly like one that did not.
Detail
Per-component generation is fanned out with return_exceptions=True
(composer/spec/natspec/pipeline.py:319), and both an exception and a give_up become
ComponentGenerationFailure entries on ContractResult.failures (pipeline.py:329,
pipeline.py:337).
The dump writes only successes (composer/ui/pipeline_app.py:210-227): each contract's interface,
its stub, and spec_results.specs. Nothing reads failures, so there is no record of which
component was lost, which properties it covered, or why it failed.
The one place a failure shows up is the per-contract count in the TUI completion banner, which is
gone as soon as the app exits. The batch cache does not help either, since a component that raised
has no cached result to inspect afterwards.
So a four-component contract that loses one writes three specs, and anyone picking up
natspec_output/ later has no way to tell that a fourth was ever attempted.
Suggested fix
Write the failures next to the specs, either as a single failures.json or as one file per failed
component, carrying the component name, its property list, and the reason string that
ComponentGenerationFailure already holds. Following the existing properties/ metadata convention
would keep it in line with what the pipeline emits today.
A closing summary line such as "3 of 4 components delivered" would help as well, and a non-zero exit
code when any component failed would make the loss visible to anything scripting the pipeline.
(ai-generated)
Summary
When a component's CVL generation fails in the greenfield natspec pipeline, nothing about it is
written to disk. The output directory holds the specs that succeeded and gives no sign that a
component is missing, so a run that lost a component looks exactly like one that did not.
Detail
Per-component generation is fanned out with
return_exceptions=True(
composer/spec/natspec/pipeline.py:319), and both an exception and agive_upbecomeComponentGenerationFailureentries onContractResult.failures(pipeline.py:329,pipeline.py:337).The dump writes only successes (
composer/ui/pipeline_app.py:210-227): each contract's interface,its stub, and
spec_results.specs. Nothing readsfailures, so there is no record of whichcomponent was lost, which properties it covered, or why it failed.
The one place a failure shows up is the per-contract count in the TUI completion banner, which is
gone as soon as the app exits. The batch cache does not help either, since a component that raised
has no cached result to inspect afterwards.
So a four-component contract that loses one writes three specs, and anyone picking up
natspec_output/later has no way to tell that a fourth was ever attempted.Suggested fix
Write the failures next to the specs, either as a single
failures.jsonor as one file per failedcomponent, carrying the component name, its property list, and the reason string that
ComponentGenerationFailurealready holds. Following the existingproperties/metadata conventionwould keep it in line with what the pipeline emits today.
A closing summary line such as "3 of 4 components delivered" would help as well, and a non-zero exit
code when any component failed would make the loss visible to anything scripting the pipeline.