The translator hangs on a small PDDL task when an action has N conditional effects that all add the same predicate (under different conditions), combined with a delete effect on that same predicate. The translator's negate_and_translate_condition (in translate_strips_operator_aux) computes product(*condition) over the N add-conditions, which is exponential — 2^N combinations.

I've attached a MWE. I couldn't figure out how to attach more than one file, so I delimited where domain.pddl and problem.pddl each start with comments

The domain models a counter (v0..v20) that decrements via conditional effects conditioned on a derived predicate trigger, plus a "refuel" mechanism where 20 conditional effects all add v20 under derived predicate special. The task has only 2 positions, 21 counter values, 3 actions, and ~80 conditional effects — trivially small — but the translator never finishes.

With v0..v3 (4 levels) it translates instantly. With v0..v20 (21 levels) it hangs. The root cause is lines 233-267 of main.py in the translator: for each variable with delete effects, it negates the DNF of all add-effect conditions via product(), producing 2^N combinations.

To reproduce: ./fast-downward.py domain.pddl problem.pddl --translate

This hangs indefinitely. With v0..v3 instead of v0..v20, it completes instantly.

I'm not sure this is a bug. Is there a way to avoid computing all combinations during grounding? If not then computing 2^21 (roughly 2 million) combinations is just a very expensive step in the translator. The fact that is works with 4 levels just means that computing 2^4 = 16 combinations is much faster than computing 2 million combinations. I think with our current semantics for conditional effects, we have to ensure that effect conditions are mutually exclusive and this requires to make a full case distinction. So I don't think the translator "hangs" in the sense that it is running in an infinite loop. You just asked it to do a very long computation.

One way to make this faster could be to change the semantics of conditional effects like we discuss in issue397 but I wouldn't see this as a bugfix, more like improving performance.