https://prefect.io logo
Join Slack
Powered by
I'm on this poetry version: Package operations: 0 ...
# marvin-ai
d
I'm on this poetry version: Package operations: 0 installs, 1 update, 0 removals - Updating controlflow (0.8.3 -> 0.9.4)
Here is another traceback I ended up getting during my testing:
Copy code
File "/home/dave/.cache/pypoetry/virtualenvs/rustmonster-GKhQY2Y4-py3.10/lib/python3.10/site-packages/prefect/task_engine.py", line 1323, in run_task_sync
    engine.call_task_fn(txn)
  File "/home/dave/.cache/pypoetry/virtualenvs/rustmonster-GKhQY2Y4-py3.10/lib/python3.10/site-packages/prefect/task_engine.py", line 786, in call_task_fn
    result = call_with_parameters(self.task.fn, parameters)
  File "/home/dave/.cache/pypoetry/virtualenvs/rustmonster-GKhQY2Y4-py3.10/lib/python3.10/site-packages/prefect/utilities/callables.py", line 206, in call_with_parameters
    return fn(*args, **kwargs)
  File "/home/dave/.cache/pypoetry/virtualenvs/rustmonster-GKhQY2Y4-py3.10/lib/python3.10/site-packages/controlflow/tasks/task.py", line 375, in run
    raise ValueError(f"{self.friendly_name()} failed: {self.result}")
ValueError: Task #d0689409 ("
j
@Dave Aitel I think your traceback got cut off
d
I tried not to paste too much :)
I do notice that the output tends to be larger than my screen while the thing is running, which makes it look very weird (I'm using anthropic) . Although it does look like someone put some work into making anthropic look a little bit more like open AI
I'm actually not sure what kind of condition would cause it not to be able to find that task
I just started my testing again though
j
That error is raised if your agent chooses to mark a task as failed (rather than a python crash or something like that). If you're calling 
cf.run()
you can pass 
raise_on_error
to disable it [although I just realized that param should be renamed 
raise_on_fail
which i will do in the next release]
There may be a message from your agent about why it failed the task -- most frequently in my experience its a broken tool that prevents it from making progress
d
In this case it noticed it didn't have some shell utility :)
j
ah ok! This is a UX i'm trying to figure out a good balance for -- if we don't give the agent some kind of escape hatch, it'll spin forever and burn tokens. But if we do let it "out" then we need to make sure that you as the operator have a way to know that the goal of the task wasn't achieved. So the compromise is we raise by default on failed tasks but allow you to suppress that (and check for e.g. 
task.is_failed()
yourself)
For testing/debug there's a useful config 
controlflow.settings.tools_raise_on_error=True
that will raise a Python error any time a tool fails
d
Imho adding failure cases is usually a bad idea with current models - I get 15% better performance by not including them (which other ppl have replicated). Models give up much too soon.
j
Oh that's so interesting. I have been adding flags for customizing which tools a task generates, so I could easily let you say e.g. "don't generate the failure tool" for a task - you'd just have to take care to provide 
max_llm_calls
or similar to ensure your agent doesnt spin forever
I'm going to open a tracking issue for that
d
That would be the way I normaly do it !
j
ok cool in that case i'll look at letting you configure a default in addition to per-task
i like that idea a lot, thanks
d
Although the reality is the biggest failure is by having too large of a context :)
j
A version of this is merged, expect release probably in the next few days: https://github.com/PrefectHQ/ControlFlow/pull/330
There's a lot of new features in this release that need testing
d
Ooh that was fast !
🙌 1
Honestly, I probably should be using the git version
But I'm actually not sure how to switch off from my current setup to that
3 Views
Open in Slack
PreviousNext
Powered by