jiangxt2 opened a new issue, #13736: URL: https://github.com/apache/gravitino/issues/13736
### Version Python client 1.3.1 and Gravitino server 1.3.1. The same close implementation is present on the main branch. ### Describe what's wrong Closing a Python Gravitino client sends an HTTP `CLOSE /` request before calling `auth_data_provider.close()`. Gravitino 1.3.1 responds with HTTP 501 Not Implemented, so a normal public client `close()` raises an exception and never invokes the authentication provider's cleanup. Calling `close()` again sends another CLOSE request and fails again. If the endpoint becomes unavailable after client construction, a connection error also prevents provider cleanup. Expected behavior: client cleanup should not depend on an unsupported HTTP method or on server availability. Repeated-close behavior should be defined explicitly. ### Error message and/or stacktrace With an available Gravitino 1.3.1 server, both close calls raise: ```text UnknownError: Unknown error handler NoneType, error response body: ErrorResponse(code=1000, type=RESTException, message=Not Implemented) ``` With an unavailable endpoint, close raises: ```text URLError: <urlopen error [Errno 111] Connection refused> ``` ### How to reproduce Start a Gravitino 1.3.1 server at `http://localhost:8090`, install `apache-gravitino==1.3.1`, and run: ```python from gravitino import GravitinoAdminClient from gravitino.auth.simple_auth_provider import SimpleAuthProvider class CountingSimpleAuthProvider(SimpleAuthProvider): def __init__(self): super().__init__() self.close_calls = 0 def close(self): self.close_calls += 1 super().close() provider = CountingSimpleAuthProvider() client = GravitinoAdminClient( uri="http://localhost:8090";, auth_data_provider=provider ) for _ in range(2): try: client.close() except Exception as error: print(type(error).__name__, str(error)) print("provider close calls:", provider.close_calls) ``` Both calls fail with UnknownError. The server receives two `CLOSE /` requests and returns 501 for each. The provider close count remains 0. To exercise the connection-failure path, construct another client successfully, stop its endpoint, then call `close()`. It raises a connection error and the provider close count remains 0. ### Additional context These behaviors occur with real HTTP traffic and an unmodified SDK/server pair in Docker. The counting subclass delegates to the real SimpleAuthProvider; it observes cleanup dispatch without replacing authentication or transport. The affected path is `clients/client-python/gravitino/utils/http_client.py`, reached through the public client's close delegation. The result establishes skipped cleanup dispatch, not a measured resource leak: SimpleAuthProvider itself has no resource to release. Since normal close already fails, this reproduction does not establish behavior after a successful close. Explicit remote session release or token revocation is outside this report. -- 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]
