GCS gfile operations fail in TF 2.17.0rc0 and 2.18 nightly when not running in GCP

[lgeiger]

GCS gfile operations fail in TF 2.17.0rc0 and 2.18 nightly when not running in GCP

[belitskiy]

Indeed, using a wheel from Feb 20 works:
gs://tensorflow-public-build-artifacts/prod/tensorflow/official/release/nightly/linux_x86_cpu/wheel_py311/391/20240220-042013/github/tensorflow/build_output/tf_nightly_cpu-2.17.0.dev20240220-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl

(there's more wheels in that bucket)

I've been able to reproduce this in one place, but it does work in a Docker container on a non-VM PC, so it's not necessarily VM-related.

So it does appear a4e3b78 is the cause.
We're looking into whether it can be rolled back

[mihaimaruseac]

@learning-to-play , this is another regression in TF 2.17 RC0

[mihaimaruseac]

This is from tsl layer, not TF-IO.

[lgeiger]

Thanks for looking into it and reproducing the issue. Also thanks for sharing the link to the older tf-nightly wheels, that's very useful to know.

[lgeiger]

The only commit that comes to mind that might influence this is a4e3b78, but I can't easily test this since tf-nightly wheels on pypi older than this date are not available.

[learning-to-play]

Please consider filing an issue in TensorFlow IO. To my knowledge there are similar issues already reported to TensorFlow IO.

FYI @yongtang @monicadsong @rtg0795

[lgeiger]

Please consider filing an issue in TensorFlow IO. To my knowledge there are similar issues already reported to TensorFlow IO.

@learning-to-play I already did at tensorflow/io#2016.
But I'm not sure that it's related to TensorFlow IO since I can only reproduce this issue with TF 2.17 but not TF 2.16 even when both of them use the same tensorflow_io_gcs_filesystem package version.

[learning-to-play]

@aaudiber Could you PTAL and help route to the right person?

[mihaimaruseac]

Probably could be "reverted" via copybara