Skip to content

ATTACH directory namespace on MinIO still fails with BucketNotFound after #208 #221

Description

@wyuxiao729

Environment

Description

I'm trying to use Lance as a namespace-backed catalog on a MinIO bucket.
The MinIO bucket and datasets already exist.
The Lance extension is built from commit 3500606, which already includes PR #208.
However, ATTACH still fails before the catalog is created.
The error is:


Failed to list tables from Lance directory namespace:
Namespace error:
Internal error:
Failed to create object store:
IO {
source: Generic {
store: "S3",
source: BucketNotFound {
bucket: "duck-lance"
}
},
location: ...
}

Existing evidence

The same secret works correctly for normal S3 operations.

For example:

CREATE SECRET (
    TYPE LANCE,
    KEY_ID '...',
    SECRET '...',
    ENDPOINT 'http://<minio>:9000',
    URL_STYLE 'path',
    USE_SSL false
);

The following operations succeed:

SELECT *
FROM glob('s3://duck-lance/**');

which_secret() also returns the correct secret:

SELECT which_secret('s3://duck-lance/path/', 's3');

returns

s3_secret

So the endpoint, credentials and bucket are all valid.


Observation

The failure happens during

ATTACH ... TYPE LANCE

before any table becomes visible.

The error message is

Failed to list tables from Lance directory namespace

instead of

Failed to open dataset

This seems different from issue #206 / PR #208.

PR #208 fixes the storage options passed to

DatasetBuilder::from_namespace(...)

However, in this case it appears the failure happens earlier, while building the directory namespace or listing tables.

Therefore DatasetBuilder::from_namespace() may never be reached.


Expected behavior

ATTACH should successfully list and attach all Lance datasets under the namespace when using a MinIO (or other S3-compatible) endpoint.


Question

Could there still be another code path where storage_options
(or specifically aws_endpoint / endpoint) are not propagated during namespace initialization?

Since #208 already fixes the dataset-open path, I'm wondering whether the namespace-build/list_tables path may still be creating an ObjectStore without the configured endpoint.

Any suggestions on where to investigate would be greatly appreciated.


I have verified that this is **not** the issue fixed by #208.

The Lance extension is built from a commit newer than #208 (`3500606`), and the patch forwarding `storage_options` via `builder.with_storage_options()` is already present in the source.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions