[Question] Is the validation behavior in keras.ops.conv_transpose intentionally different between symbolic and eager paths?

[AkshatRaj00]

Summary

I noticed a behavior mismatch in keras.ops.conv_transpose between the symbolic and eager execution paths.

Observation

It looks like the eager path fails earlier when input channels are invalid, while the symbolic path does not enforce the same validation in the same way and may allow the invalid shape to proceed further.

Expected behavior

If this difference is intentional, it would be helpful to document it clearly. If not, both paths should probably enforce the same input-channel validation so the user-facing behavior stays consistent.

Why this matters

This kind of mismatch makes debugging harder and can lead to backend-specific failures that are not obvious from the original error.

Question

Is this difference intentional, or should it be treated as a validation bug?

Optional note

If helpful, I can try to provide a minimal repro snippet for the exact behavior I’m seeing.

[starkmarkus]

I’d expect eager and symbolic to behave the same here from a user point of view.

If eager fails immediately on invalid input channels but symbolic lets it get further, that feels inconsistent rather than intentional.

Some difference in when the check happens is understandable, since symbolic execution can’t always validate everything right away. But the end result should still be the same: invalid conv_transpose input should fail clearly in both paths.

So unless there’s a reason for this split behavior, I’d treat it as a bug and make the validation consistent.

If helpful, I can also share a minimal repro for the exact case I hit.

[Sameekshagithub]

Thanks for reporting this.

From a user perspective, the behavior should ideally be consistent between eager and symbolic execution paths. Keras APIs generally try to provide the same validation behavior regardless of whether tensors are concrete or symbolic.

The difference may come from where the shape/channel validation is performed internally. In eager execution, the actual tensor information is available immediately, while symbolic execution relies on shape inference during graph construction.

A minimal reproducible example showing:

• backend being used (TensorFlow/JAX/PyTorch),
• Keras version,
• input shape,
• expected vs actual error behavior,

would help determine whether this is an intentional limitation or a validation inconsistency.

If the symbolic path can accept an invalid channel dimension that later causes a backend failure, adding the same validation during symbolic shape inference would likely make the API behavior more predictable.

[dev-jinwoohong]

In Keras 3.15.1, the symbolic path now explicitly checks the input channels before inferring the output shape. The TensorFlow backend calls the same validator.

For example, this has three input channels but a kernel expecting four, so it should raise ValueError during symbolic construction:

import keras

x = keras.KerasTensor((None, 8, 8, 3))
kernel = keras.KerasTensor((3, 3, 5, 4))
keras.ops.conv_transpose(x, kernel, data_format="channels_last")

The transposed-convolution kernel layout is (spatial..., output_channels, input_channels), so the comparison uses its last dimension.

The remaining distinction is an unknown channel dimension: the validator only compares two concrete integers. If a symbolic channel count is None, that check has to wait until the dimension is known. Your Keras version and whether the mismatched dimensions are concrete would distinguish these cases.

[AkshatRaj00]

Thanks @dev-jinwoohong for the detailed clarification and confirmation.

Glad to see that explicit channel validation has been aligned in Keras 3.15.1 for concrete dimensions during symbolic construction. That completely answers the question!