Version: 2.11.0
MAX_WORKFLOW_SECONDS = 60.0 in skillspector/state.py is the aggregate deadline for a whole scan
workflow, consumed by WorkflowResourceBudget.remaining_seconds(). On a large skill the budget is
exhausted part-way through, and the scan returns a partial result with truncation_reasons
populated and coverage_percent below 100.
There is currently no way to raise it: no CLI flag sets a budget or timeout, and the only
environment override anywhere in the package is SKILLSPECTOR_OSV_TIMEOUT in
nodes/analyzers/osv_client.py.
Why this is a problem rather than a preference. We use a complete scan as an intake gate on
third-party skills — a skill is not accepted until it has a scan with full coverage. A skill large
enough to reliably exceed 60 seconds therefore cannot pass the gate at all, because it cannot
produce the artifact the gate requires. Observed on a 147-file skill: five of six whole-skill
attempts truncated, with coverage varying between 0% and 100% run to run purely on timing.
A truncated result is not simply a subset of a complete one, which is what makes the partial
output hard to work with. On the same skill, the truncated whole-skill run reported 69 findings at
63.3% coverage, while a complete run over disjoint decomposed units reported 29 findings at
100%. Units scanned in isolation lose reference-graph relationships that cross unit boundaries, so
more coverage legitimately produced fewer findings. A consumer cannot treat a truncated run as "the
complete run minus what it missed".
Request. Make the aggregate budget configurable, keeping 60s as the default.
WorkflowResourceBudget.max_seconds is already a defaulted dataclass field, so either would work:
- a
SKILLSPECTOR_MAX_WORKFLOW_SECONDS environment variable, mirroring the existing
SKILLSPECTOR_OSV_TIMEOUT handling exactly; or
- a
--max-seconds CLI flag threaded into the budget at construction.
An env var alone would be enough for our case and matches precedent already in the codebase.
Current workaround, and why it is not sufficient. We decompose a large skill into disjoint
subdirectory units, scan each within the 60s budget, recurse where a unit still truncates, and
aggregate (sum severities, max the score, file-count-weighted mean coverage). It does produce a
complete scan, but it costs the cross-unit context described above and takes roughly 20 minutes of
wall clock for one skill, so it cannot run interactively.
Version: 2.11.0
MAX_WORKFLOW_SECONDS = 60.0inskillspector/state.pyis the aggregate deadline for a whole scanworkflow, consumed by
WorkflowResourceBudget.remaining_seconds(). On a large skill the budget isexhausted part-way through, and the scan returns a partial result with
truncation_reasonspopulated and
coverage_percentbelow 100.There is currently no way to raise it: no CLI flag sets a budget or timeout, and the only
environment override anywhere in the package is
SKILLSPECTOR_OSV_TIMEOUTinnodes/analyzers/osv_client.py.Why this is a problem rather than a preference. We use a complete scan as an intake gate on
third-party skills — a skill is not accepted until it has a scan with full coverage. A skill large
enough to reliably exceed 60 seconds therefore cannot pass the gate at all, because it cannot
produce the artifact the gate requires. Observed on a 147-file skill: five of six whole-skill
attempts truncated, with coverage varying between 0% and 100% run to run purely on timing.
A truncated result is not simply a subset of a complete one, which is what makes the partial
output hard to work with. On the same skill, the truncated whole-skill run reported 69 findings at
63.3% coverage, while a complete run over disjoint decomposed units reported 29 findings at
100%. Units scanned in isolation lose reference-graph relationships that cross unit boundaries, so
more coverage legitimately produced fewer findings. A consumer cannot treat a truncated run as "the
complete run minus what it missed".
Request. Make the aggregate budget configurable, keeping 60s as the default.
WorkflowResourceBudget.max_secondsis already a defaulted dataclass field, so either would work:SKILLSPECTOR_MAX_WORKFLOW_SECONDSenvironment variable, mirroring the existingSKILLSPECTOR_OSV_TIMEOUThandling exactly; or--max-secondsCLI flag threaded into the budget at construction.An env var alone would be enough for our case and matches precedent already in the codebase.
Current workaround, and why it is not sufficient. We decompose a large skill into disjoint
subdirectory units, scan each within the 60s budget, recurse where a unit still truncates, and
aggregate (sum severities, max the score, file-count-weighted mean coverage). It does produce a
complete scan, but it costs the cross-unit context described above and takes roughly 20 minutes of
wall clock for one skill, so it cannot run interactively.