feat(rag): add StorageBase interface for encrypted storage

[Achieve3318]

Design Purpose

• Define a formal storage abstraction
  Introduce StorageBase in rag/utils/storage_base.py as the canonical interface for storage backends used with encrypted storage. It declares the required operations (put, get, rm, obj_exist, health) instead of relying on ad-hoc hasattr checks.

• Make EncryptedStorageWrapper safer and self-documenting
  EncryptedStorageWrapper now expects a StorageBase implementation (with a defensive runtime check). This clarifies what backends must provide, reduces the risk of partially implemented or incompatible backends, and makes it easier for new backends (MinIO, S3, filesystem, etc.) to integrate by implementing one interface.

• Enable local, dependency-free tests for storage behavior
  Add an in-memory InMemoryStorage implementation and unit tests in test_storage_base.py so the storage contract can be validated without external services or configuration.

File Changes

Modified files

rag/utils/encrypted_storage.py (+3, -3)

• Import: from rag.utils.storage_base import StorageBase.
• EncryptedStorageWrapper.__init__: parameter type hint storage_impl: StorageBase.
• Updated comment: replaced TODO with note that backends should implement StorageBase, with defensive runtime checks for duck typing.

Type of change

• Bug Fix (non-breaking change which fixes an issue)
• New Feature (non-breaking change which adds functionality)
• Documentation Update
• Refactoring
• Performance Improvement
• Other (please describe):

[Achieve3318]

Hi, @yingfeng , Please review my PR. Thanks

[Achieve3318]

Hi, @KevinHuSh , Could you review my PR if you have time? Thanks

[yingfeng]

What's the design purpose of this PR?

[Achieve3318]

What's the design purpose of this PR?

Hi, @yingfeng , Thank you for your review. I updated description of this PR. Please check again.

[yingfeng]

I meant why introducing a base class for EncryptedStorage? It's just a utility to wrap up other S3 storage. There does not exist a so-called in-memory storage, and then adding new storage type as MinIO, S3,...,etc because those storage types already exists and they are not based on your newly defined StorageBase.

[Achieve3318]

@yingfeng , Thanks for the feedback. I’ve removed the StorageBase abstraction and the in-memory storage type.

The EncryptedStorageWrapper is now kept as a thin, duck-typed utility around the existing storage backends (MinIO/S3, etc.). It simply validates at runtime that the wrapped implementation exposes the minimal method set it relies on (put, get, rm, obj_exist, health), without introducing a new base class or new storage type.

[Achieve3318]

Hi, @yingfeng , Could you review my PR again? Thank you

[yingfeng]

So, what's left in this PR?

[Achieve3318]

So, what's left in this PR?

At this point the PR is very small

• EncryptedStorageWrapper is still just a thin, duck-typed wrapper over the existing storage implementations (MinIO/S3/etc.).
• The only behavior it enforces is a runtime check that the wrapped storage has the minimal method set it already relies on: put/get/rm/obj_exist/health.
• The previous StorageBase abstraction and in-memory storage/test have been removed, so there are no new storage types or base classes introduced.

[Achieve3318]

I replaced TODO with note that backends should implement StorageBase, with defensive runtime checks for duck typing.

[yingfeng]

I can only see some comments

[Achieve3318]

I can only see some comments

oh, sorry, I had mistake. Please review again. Thank you for your review

[Achieve3318]

@yingfeng , If you have time, please check my updates again. Thank you

[Achieve3318]

@yingfeng . Please check my PR if you have time