Open nicholasjng opened 1 week ago
This might be a little harder than I thought - we're just handing off the lakefs.ObjectReader
(or Writer) to the user, and that is what produces the error in its .close()
method when trying to send the buffer to the server.
Since the user voluntarily takes ownership of these object readers and writers when using them outside of a context manager (or even within? I don't see error translating anywhere here tbh), there might not be a lot we can do here, since we're not "within" our file system anymore.
EDIT: At least not without subclassing the ObjectReader and Writer classes to add something to the .close()
.
What happened?
We have an exception translator that translates lakefs API exceptions to builtin Python exceptions to ensure conformity of our fsspec implementation.
I just tried streaming JSON data directly into lakeFS for our nnbench project with a command like this:
Details are not as important, it just calls
fs.open()
under the hood and passes the resulting file descriptor off tojson.dump()
. When attempting to write that file in a fresh lakeFS quickstart repo like above, I get the following exception:So it seems that we're missing a
raise translate_lakefs_error()
somewhere inLakeFSFileSystem.open()
.What did you expect to happen?
I expected something like
PermissionError: cannot write to protected branch 'main'
, but the branch name would probably be sugar on top in our exception facility. There have been a few instances where I wanted more detail from lakeFS exceptions, but some (or all) of it is just the scarcity of info you get from the server.lakeFS-spec version
0.11.0
lakeFS version
1.42.0