The scorer returned {'acc': ...} while the recipe registers the metric
as 'resolved' -- the aggregator looked for 'resolved' in scores, found
nothing, and reported 0.0 despite per-sample resolved=1.0 in the
checkpoint. Key names now match the recipe registration.
Co-Authored-By: Claude <noreply@anthropic.com>
get_eval_report returns {instance_id: {resolved: bool, ...}}, not a flat
dict. report.get('resolved') was always None -> every sample scored 0
despite the grader judging resolved=true (confirmed by direct grader
call on the real test output: astropy-13453 resolved=true).
Co-Authored-By: Claude <noreply@anthropic.com>
sample.metadata vs env_state mismatch confirmed: sample[0] said
astropy-12907 while the paired prediction held 13453's test_patch --
make_test_spec built the eval_script for the WRONG bug, scoring real
patches against wrong tests (0/10 despite manual verification that
the patches are correct). The env_state IS the actual instance the
agent ran; it takes priority, sample.metadata fills gaps.
Co-Authored-By: Claude <noreply@anthropic.com>
The official eval_script runs pip install -e '.[test]' -- same pypi.org
unreachability as agent containers would burn the 1800s timeout on
network retries. Same tuna mirror injected.
Co-Authored-By: Claude <noreply@anthropic.com>
Both swe variants now score through make_test_spec -> container ->
apply-patch -> official eval_script -> get_eval_report -- the exact
pipeline es's eval_instance drives (swebench==4.1.0 installed). Our
in-container protocol stays as fallback when the package is absent.
env_reward gains a recipe-level 'backend' delegation hook (tau2's
reward_info reader and the swe official scorer both ride it); the
generic bfcl call-sequence comparison remains the default.
Co-Authored-By: Claude <noreply@anthropic.com>
tau2's current reward_info carries 'reward' (composite) + db_check /
action_checks; the scorer read the old environment_reward /
communication_reward split that no longer exists -- simulations scored
1.0 came out 0.0. Fallback to the old split kept for older engines.
Co-Authored-By: Claude <noreply@anthropic.com>
The official image's ENTRYPOINT is 'python3 -m bigcodebench.evaluate'
-- our 'python /work/main.py' runner was swallowed as CLI args and the
official evaluator died on 'No samples provided'. execution scorer now
accepts entrypoint= and docker exec passes --entrypoint; the BCB recipe
sets entrypoint python3. Also swept 7 leaked eh-exec containers (the
--rm path never fires when our timeout kills the CLI first).
Co-Authored-By: Claude <noreply@anthropic.com>
1140 real predictions scored 0.0% because the recipe referenced
'bigcodebench-sandbox:latest' -- a name nothing builds and docker.io
does not have; every sample then burned 3 pull-retries (~200s each).
- image -> bigcodebench/bigcodebench-evaluate:latest (the official hub
image, same one evalscope uses)
- ensure_image() preflight in evaluate(): recipe-level AND sample-level
images are verified/pulled ONCE before any container runs; missing ->
seconds-fast bench failure with a fix hint instead of a silent 0.0%
- docker exec: 'Unable to find image'/'manifest unknown' class errors
are permanent -- no 3x retry amplification
Verified with a bogus image: preflight raises in one pull-attempt with
the fix hint.
Co-Authored-By: Claude <noreply@anthropic.com>
