`cirq.decompose_once` fails when called on `cirq.CZ` about cirq

[NoureldinYosri]

what is the desired behaviour here? I think cirq.CZ is treated as a native gate so operations decompose into it but it doesn't have its own decomposition

[maffoo]

I don't know what the expected behavior is; I guess maybe the idea here is that if an op can't be decomposed this is supposed to raise? The docs for decompose_once are not very clear on this, and obviously the behavior of decompose is different. Maybe decompose_once is intended to be something like "decompose exactly once" versus "decompose at most once".

[dstrain115]

cirq cync: The root cause which spawned this issue could be a problem with multiprocessing, since there is global state keeping track of this table. This global state is only in the calling code, not in cirq itself.

Conclusion is that this is intended behavior, since decompose_once should return exception denoting that you are at the base case.

The sole action item here is to document the behavior of decompose_once when you specify a "base gate".
Nice to have would be to have a specialized exception type (or a more helpful message).