Catch wrong credentials for pSQL

[Kowlin]

The fact that no one caught this after all these years... is kinda funny!

(venv) C:\Users\oriko\coding\red>redbot ori299
The main bot task didn't handle an exception and has crashed
Traceback (most recent call last):
  File "C:\Users\oriko\coding\red\venv\Lib\site-packages\redbot\__main__.py", line 470, in red_exception_handler
    red_task.result()
  File "C:\Users\oriko\coding\red\venv\Lib\site-packages\redbot\__main__.py", line 315, in run_bot
    await driver_cls.initialize(**data_manager.storage_details())
  File "C:\Users\oriko\coding\red\venv\Lib\site-packages\redbot\core\_drivers\postgres\postgres.py", line 47, in initialize
    cls._pool = await asyncpg.create_pool(**storage_details)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\oriko\coding\red\venv\Lib\site-packages\asyncpg\pool.py", line 403, in _async__init__
    await self._initialize()
  File "C:\Users\oriko\coding\red\venv\Lib\site-packages\asyncpg\pool.py", line 430, in _initialize
    await first_ch.connect()
  File "C:\Users\oriko\coding\red\venv\Lib\site-packages\asyncpg\pool.py", line 128, in connect
    self._con = await self._pool._get_new_connection()
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\oriko\coding\red\venv\Lib\site-packages\asyncpg\pool.py", line 502, in _get_new_connection
    con = await connection.connect(
          ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\oriko\coding\red\venv\Lib\site-packages\asyncpg\connection.py", line 2329, in connect
    return await connect_utils._connect(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\oriko\coding\red\venv\Lib\site-packages\asyncpg\connect_utils.py", line 991, in _connect
    conn = await _connect_addr(
           ^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\oriko\coding\red\venv\Lib\site-packages\asyncpg\connect_utils.py", line 828, in _connect_addr
    return await __connect_addr(params, True, *args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\oriko\coding\red\venv\Lib\site-packages\asyncpg\connect_utils.py", line 876, in __connect_addr
    await connected
asyncpg.exceptions.InvalidPasswordError: password authentication failed for user "oriko"
Attempting to die as gracefully as possible...
Task exception was never retrieved
future: <Task finished name='Task-2' coro=<shutdown_handler() done, defined at C:\Users\oriko\coding\red\venv\Lib\site-packages\redbot\__main__.py:425> exception=AttributeError("'Red' object has no attribute '_AutoShardedClient__queue'")>
Traceback (most recent call last):
  File "C:\Users\oriko\coding\red\venv\Lib\site-packages\redbot\__main__.py", line 441, in shutdown_handler
    await red.close()
  File "C:\Users\oriko\coding\red\venv\Lib\site-packages\redbot\core\bot.py", line 2178, in close
    await super().close()
  File "C:\Users\oriko\coding\red\venv\Lib\site-packages\discord\ext\commands\bot.py", line 247, in close
    await super().close()  # type: ignore
    ^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\oriko\coding\red\venv\Lib\site-packages\discord\shard.py", line 498, in close
    await self._closing_task
  File "C:\Users\oriko\coding\red\venv\Lib\site-packages\discord\shard.py", line 495, in _close
    self.__queue.put_nowait(EventItem(EventType.clean_close, None, None))
    ^^^^^^^^^^^^
AttributeError: 'Red' object has no attribute '_AutoShardedClient__queue'

[japandotorg]

Should config fallback to use the JSON driver with a specified message sent to the bot owner(s) if postgres credentials are wrong?

[Flame442]

I would think not, as that would be an entirely separate set of data. I would say not being able to load its data because the credentials are incorrect should cause the bot to exit with the "configuration error" status code (78).

Red-DiscordBot/redbot/core/_cli.py

Line 26 in 30058c0

CONFIGURATION_ERROR = 78 # Exit code borrowed from os.EX_CONFIG.

Though I am curious how we handle the database not running when the bot starts. This can probably be handled in a similar way to that as well.

[japandotorg]

Does Red initially tries to connect to postgres when starting the bot, or does it only connect individually to postgres when a cog uses Config?

[japandotorg]

is there like any "first guaranteed call to postgres" when Red initially starts when using the postgres driver?

[Flame442]

Red-DiscordBot/redbot/__main__.py

Lines 300 to 315 in 30058c0

	async def run_bot(red: Red, cli_flags: Namespace) -> None:
	"""
	This runs the bot.
	Any shutdown which is a result of not being able to log in needs to raise
	a SystemExit exception.
	If the bot starts normally, the bot should be left to handle the exit case.
	It will raise SystemExit in a task, which will reach the event loop and
	interrupt running forever, then trigger our cleanup process, and does not
	need additional handling in this function.
	"""
	driver_cls = _drivers.get_driver_class()
	await driver_cls.initialize(**data_manager.storage_details())

Red-DiscordBot/redbot/core/_drivers/postgres/postgres.py

Lines 42 to 47 in 30058c0

	async def initialize(cls, **storage_details) -> None:
	if asyncpg is None:
	raise errors.MissingExtraRequirements(
	"Red must be installed with the [postgres] extra to use the PostgreSQL driver"
	)
	cls._pool = await asyncpg.create_pool(**storage_details)

Currently the pool is created in run_bot (which is before bot.start()), without any guards for if the pool is not online or the password is incorrect. I still would be inclined to say that the entire driver_cls.initialize call should be wrapped in a try/except that sys.exit(ExitCodes.CONFIGURATION_ERROR) on exception.

[japandotorg]

Shouldn't this also be handled when lets say the creds changed during runtime?

[Kowlin]

Shouldn't this also be handled when lets say the creds changed during runtime?

That sounds like a very specific edge case. Credentials don't normally change during runtime. So in my opinion its fine to skip over it.

[Flame442]

The database going offline during runtime is a less rare edge case than the credentials changing, and both would be handled similarly, so I don't think it's unreasonable to consider. That being said, it's less clear where it would be best to catch these errors during runtime, and it's less likely to be an issue than not configuring the connection correctly at the start. I'd say that handling these on bot start is much more important, and should be the main focus for someone working on this issue. Catching similar errors during runtime wouldn't hurt, but I think is lower priority.