[Bug] Getting ConnectError when expecting AuthenticationError

首先使用 Python 用戶端針對所述 Pulsar 服務版本重現格式錯誤權杖的情況，然後追蹤 C++ 用戶端對驗證失敗的處理。完成的標準是，格式錯誤或未獲授權的權杖以 AuthenticationError 的形式呈現，而網路故障仍以 ConnectError 的形式呈現。

Search before asking

• I searched in the issues and found nothing similar.

Version

pulsar-all image version 2.10.32 and pulsar-all image version 2.11.0
Token auth enabled
Python client version 2.10.1

Minimal reproduce step

Token auth is correctly set up and tested to be working with a good token.

Again, with token auth enabled, try to connect with a (python) client and provide a broken token (try various ways to break it, including a malformed token).

I tried this with a standard token mechanism, but I also tried this with a custom Auth plugin where other token fields can be broken in similar ways.

What did you expect to see?

Expect a ConnectError when there are network reasons for not being able to establish connection.

Expect an AuthenticationError with a well-formed token without permission to use Pulsar resources.

Expect an AuthenticationError when there is a bad token; but get ConnectError.

We got reports from users that ConnectError was confusing when debugging issues.

What did you see instead?

ConnectError when a bad token is provided.

    bad_admin_token = "eyJhbGciOiJIUzI1aaaaaaaNiJ9.eyJzdWIiOiJhZG1pbiJ9.1Eu3ph4RneevmKIKlE9gglAAyFBJMeN7GM-ZnHLZNsM" # ConnectError
    pulsar_service_url = 'pulsar://localhost:6650/'
    client = pulsar.Client(pulsar_service_url, authentication=pulsar.AuthenticationToken(bad_admin_token))

    try:
        producer = client.create_producer('my-topic')
        for i in range(10):
            producer.send(('Hello-%d' % i).encode('utf-8'))
        client.close()
    except Exception as e:
        print(e.args)
        print(dir(e))
        print()
        raise

Get this result:

2023-03-21 10:53:02.074 INFO  [0x306688000] ExecutorService:41 | Run io_service in a single thread
2023-03-21 10:53:02.075 INFO  [0x202b38600] ClientConnection:189 | [<none> -> pulsar://localhost:6650/] Create ClientConnection, timeout=10000
2023-03-21 10:53:02.086 INFO  [0x202b38600] ConnectionPool:96 | Created connection for pulsar://localhost:6650/
2023-03-21 10:53:02.129 INFO  [0x306688000] ClientConnection:375 | [[::1]:64418 -> [::1]:6650] Connected to broker
2023-03-21 10:53:02.953 INFO  [0x306688000] ClientConnection:1560 | [[::1]:64418 -> [::1]:6650] Connection closed
2023-03-21 10:53:02.954 ERROR [0x306688000] ClientImpl:194 | Error Checking/Getting Partition Metadata while creating producer on persistent://public/default/my-topic -- ConnectError
2023-03-21 10:53:02.954 ERROR [0x306688000] ClientConnection:597 | [[::1]:64418 -> [::1]:6650] Read operation failed: Bad file descriptor
2023-03-21 10:53:02.955 INFO  [0x306688000] ClientConnection:263 | [[::1]:64418 -> [::1]:6650] Destroyed connection
('Pulsar error: ConnectError',)
['__cause__', '__class__', '__context__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__le__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__setstate__', '__sizeof__', '__str__', '__subclasshook__', '__suppress_context__', '__traceback__', '__weakref__', 'args', 'with_traceback']

2023-03-21 10:53:02.967 INFO  [0x306688000] ExecutorService:47 | Event loop of ExecutorService exits successfully
Traceback (most recent call last):
  File "/Users/******/PycharmProjects/pythonProject/local.py", line 36, in <module>
    print_hi('PyCharm')
  File "/Users/******/PycharmProjects/pythonProject/local.py", line 24, in print_hi
    producer = client.create_producer('my-topic')
  File "/Users/thors/PycharmProjects/pythonProject/venv/lib/python3.9/site-packages/pulsar/__init__.py", line 603, in create_producer
    p._producer = self._client.create_producer(topic, conf)
_pulsar.ConnectError: Pulsar error: ConnectError

Process finished with exit code 1

Again, our users complain that this error is hard to debug in logs because it would have you troubleshoot connectivity rather than problems with authentication setup.

Anything else?

I have tested this with both an admin token and lesser permissions tokens.
I have also tested breaking the token in various parts that would fail to parse it.
Also tested against a custom Auth plugin where we implement token checks.

Are you willing to submit a PR?

• I'm willing to submit a PR!