aisix-obs: object_store sink ignores `endpoint` for GCS — wire `with_base_url` or drop the schema allowance

[moonming]

Summary

In crates/aisix-obs/src/sink/object_store.rs, build_object_store's GCS arm never consumes the endpoint parameter — only bucket + the service-account key. The S3 arm (with_endpoint, path-style, allow-http for loopback) and the Azure arm (MicrosoftAzureBuilder::with_endpoint, Azurite) both honor it.

The comment there says GCS "has no HTTP-endpoint override on the builder" — that's stale: object_store 0.13 (the pinned version) exposes GoogleCloudStorageBuilder::with_base_url and GoogleConfigKey::BaseUrl (google_base_url), which take precedence over the service-account JSON's gcs_base_url.

Meanwhile the watch-path config schema still allows endpoint for any provider and its loopback pattern explicitly allowlists fake-gcs-server / fake-gcs hostnames — an allowance nothing can use while the GCS arm ignores the field. A configured endpoint on a gcs exporter is silently dead today.

Options

(a) Wire it — endpoint → with_base_url in the GCS arm, mirroring the S3/Azure arms (incl. allow_http for the loopback emulator hosts). Gives provider symmetry and makes the fake-gcs-server emulator path work through the normal config field instead of riding gcs_base_url inside the credential JSON.

(b) Make the ignore official — remove fake-gcs-server / fake-gcs from the schema's endpoint pattern, document that GCS emulator/private base URLs ride the service-account JSON's gcs_base_url, and reject (or keep ignoring, but document) endpoint for gcs at config validation.

Either way, the stale "no host override" comment in the GCS arm should be corrected.

Notes

• gcs_base_url in the service-account JSON is real and honored (object_store ServiceAccountCredentials.gcs_base_url → client base URL), so the current workaround stands regardless.
• If (a) lands, control-plane-side validation that assumes endpoint-is-ignored-for-gcs can be relaxed in step.