"cannot unpack non-iterable NoneType object."

[blairdrummond]

Seems idiosyncratic, but on some folders, I get this error

However the folder is not empty, I can see the contents in minio. I don't have any fancy policies, though I don't know this tech well. Error on the notebook server is below

Traceback (most recent call last):
  File "/opt/conda/lib/python3.7/site-packages/jupyterlab_s3_browser/__init__.py", line 230, in do_get_object
    response = s3client.get_object(Bucket=bucket_name, Key=path)
  File "/opt/conda/lib/python3.7/site-packages/botocore/client.py", line 316, in _api_call
    return self._make_api_call(operation_name, kwargs)
  File "/opt/conda/lib/python3.7/site-packages/botocore/client.py", line 626, in _make_api_call
    raise error_class(parsed_response, operation_name)
botocore.errorfactory.NoSuchKey: An error occurred (NoSuchKey) when calling the GetObject operation: The specified key does not exist.
[I 03:22:16.904 NotebookApp] Build is up to date

As I said, the folders definitely exist

[blairdrummond]

It seems to not play nice with folders within buckets in general? Does it expect a flat file layout?

[reevejd]

Thanks for opening the issue. It's supposed to work for any file layout. I'll take a look later today.

[reevejd]

I'm able to reproduce the issue. Unless I'm mistaken it's minio specific, which is surprising. I fully intend for this extension to support minio so I'll continue looking into it. Thanks again for raising the issue.

[blairdrummond]

Yeah I did run this on minio; I should have mentioned that!

[ptitzler]

I was able tools recreate the issue using a COS instance on IBM Cloud:

• create a bucket (e.g. s3://mybucket/)
• create objects with key name prefixes (e.g. s3://mybucket/prefix1/object1, s3://mybucket/prefix2/prefix3/object2)
• Open the bucket in the S3 browser
• Drilling down on one of the prefixes (prefix1 or prefix2) the key error is raised.

Looking at the code it appears that during that operation a call is made to s3client.get_object(Bucket=bucket_name, Key=path) e.g. s3client.get_object(Bucket=mybucket, Key=prefix1), which triggers the 404/not found.

Digging a bit more into the code get_s3_objects_from_path(s3, path) in __init__.py appears to treat path as a "directory" if it ends with /. For some unknown reason (I haven't look at the labextension) the trailing slash is never present if path refers to a key prefix, e.g. prefix1 . Therefore these requests always result in a do_get_object call instead of a do_list_objects_v2 call.

Hope this helps!

[reevejd]

Thanks for the info. I believe this has now been fixed in the most recent releases for JupyterLab 1.x and 2.x. Please reopen this issue if you continue to encounter it after updating. Thanks!

[jarutis]

Still seeing this Amazon S3 and

jupyterlab==2.2.2
jupyterlab-s3-browser==0.6.1

I can provide more info if there is something that would help.

[reevejd]

@jarutis what version of the labextension are you using? You can run jupyter labextension list to show the versions of all the labextensions you have installed.

[invision-bot]

Here they are:

JupyterLab v2.2.2
Known labextensions:
   app dir: /home/ubuntu/conda/share/jupyter/lab
        @jupyter-voila/jupyterlab-preview v1.1.0  enabled  OK
        @jupyter-widgets/jupyterlab-manager v2.0.0  enabled  OK
        @jupyterlab/git v0.20.0  enabled  OK
        @krassowski/jupyterlab-lsp v1.1.2  enabled  OK
        @ryantam626/jupyterlab_code_formatter v1.3.6  enabled  OK
        jupyter-matplotlib v0.7.3  enabled  OK
        jupyterlab-s3-browser v0.4.1  enabled  OK
        nbdime-jupyterlab v2.0.0  enabled  OK

[reevejd]

Sorry for the delayed response. if you update from version 0.4.1 to 0.6.1 it should resolve the issue. If not, please let me know.