You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Online runs don't save responses that parse_func rejects, so re-runs pay for them again #744
If parse_func returns [] to drop rows, the default require_all_responses=True makes every run fail with Some requests do not have responses and require_all_responses is True., and each re-run sends the dropped rows again.
Since 74f0463 ("ref: skip parse func failure"), a parse_func exception skips the response instead of stopping the run. 32f94c7 ("ref: add processor response method in base") then moved the parsing into _process_response and added if not responses: return in append_generic_response, which also drops [] results.
Repro (no API key: a small OpenAI-compatible stub on 127.0.0.1)
$ python repro_parse_func.py
run 1: Some requests do not have responses and require_all_responses is True.
responses saved after run 1: 8 of 10 requests sent
run 2 (parse fixed): requests sent: 2
$ python repro_filter.py
run 1: Some requests do not have responses and require_all_responses is True. (requests sent: 10)
run 2: Some requests do not have responses and require_all_responses is True. (requests sent: 2)
run 3: Some requests do not have responses and require_all_responses is True. (requests sent: 2)
Expected: every response is saved whatever parse_func returns; the re-run with the fixed parse_func sends 0 requests; rows dropped with [] don't count as missing.
The batch path has a similar early return for parse_func errors (base_batch_request_processor.py L606-L610), but there None also covers responses that don't match response_format, so I've kept this issue to online mode. (Batch mode does save [] results, since it checks is None.)
Environment: macOS 26.6.2, Python 3.11.17, curator main 31abdb7.
In online mode,
append_generic_responsereturns before writing a response toresponses_0.jsonlwhenparse_funcraises or returns[]:curator/src/bespokelabs/curator/request_processor/online/base_online_request_processor.py
Lines 622 to 631 in 31abdb7
The request was sent and paid for, but the response isn't saved. Two things follow:
parse_funcraises for some rows, fixing it and re-running the same job sends those requests again. The run directory is the same (the cache fingerprint doesn't includeparse_func), but the responses were never written. Changing parse func should not invalidate the cache #40 and Prevent .arrow file getting in an invalid state and generate different .arrow based on parse_func #61 set up the cache so you can fixparse_funcwithout re-running LLM calls; this path skips that.parse_funcreturns[]to drop rows, the defaultrequire_all_responses=Truemakes every run fail withSome requests do not have responses and require_all_responses is True., and each re-run sends the dropped rows again.Since 74f0463 ("ref: skip parse func failure"), a
parse_funcexception skips the response instead of stopping the run. 32f94c7 ("ref: add processor response method in base") then moved the parsing into_process_responseand addedif not responses: returninappend_generic_response, which also drops[]results.Repro (no API key: a small OpenAI-compatible stub on 127.0.0.1)
stub_server.py:repro_parse_func.py:repro_filter.py:Output on main (31abdb7):
Expected: every response is saved whatever
parse_funcreturns; the re-run with the fixedparse_funcsends 0 requests; rows dropped with[]don't count as missing.The batch path has a similar early return for
parse_funcerrors (base_batch_request_processor.pyL606-L610), but thereNonealso covers responses that don't matchresponse_format, so I've kept this issue to online mode. (Batch mode does save[]results, since it checksis None.)Environment: macOS 26.6.2, Python 3.11.17, curator main 31abdb7.