chitralverma opened a new pull request, #7908: URL: https://github.com/apache/opendal/pull/7908
# Which issue does this PR close? Closes #7904. # Rationale for this change `OperatorRegistry` already stores every registered scheme in its internal `factories: Mutex<HashMap<String, OperatorFactory>>`, but there was no public way to read those keys back. For the global registry, that set is exactly what `Operator::from_uri` can construct, and it is otherwise unobservable at runtime (it is fully determined by the compiled-in `services-*` features). Without it, a common mistake — a wrong dialect (`s3a://`, `gs://` vs `gcs://`) or a missing `services-*` feature — yields a bare `scheme is not registered` error with no hint about which schemes *are* available. # What changes are included in this PR? - Add `OperatorRegistry::schemes() -> HashSet<String>`, a thin read over the existing `factories` map under the current lock. No new state, no other API surface. - Enrich the `from_uri` `scheme is not registered` error with an `available` context that lists the registered schemes (sorted), turning a bare error into an actionable hint. - Add unit tests covering the accessor and the enriched error, plus a doctest on `schemes()`. # Are there any user-facing changes? Yes, additive only: - New public method `OperatorRegistry::schemes()`. - The `from_uri` unsupported-scheme error now carries an additional `available` context field listing registered schemes. No existing field or error kind changes; not a breaking change. ## Note on the reviewer question (mapping vs list) @erickguan asked whether a scheme -> service mapping would be preferable to a flat set, since multiple schemes can map to one service. The registry currently stores `scheme -> factory fn` with the concrete `Builder`/service type erased at registration, so it cannot produce a scheme -> service mapping without capturing service identity as new state. This PR keeps the minimal, no-new-state accessor as scoped in the issue. Exposing a scheme -> service mapping can be layered on later once service identity is tracked at `register()` time; happy to follow up in a separate PR if that direction is preferred. # AI Usage Statement This PR was prepared with the assistance of an AI coding agent (OpenCode, using an Anthropic Claude model) for implementation and drafting. All changes were reviewed by a human before submission. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
