responding to a slash command with attachment=hikari.URL(<invalid url>) causes some issues | hikari | Page 1

eternal hearth Jun 22, 2024, 1:33 PM

#

when doing the following:

await ctx.respond('None', attachment=hikari.URL('https://sdfgfksfgjskfhjgksdfhjgksdgsdfgsd.com'))```out of an arc slash command it causes an `AttributeError: '_RequestContextManager' object has no attribute '_resp'` while i'd expect it to controllably raise something like a `hikari.BadRequestError` and it can be caught with a try-except but it causes an asyncio error to be shown in the console regardless if it was caught or not which is not a good sign

I don't know if this is a bug but having to test your URLs beforehand manually seems wrong if there's a `aiohttp.client_exceptions.ClientConnectorError` raised on the way to the attribute error ("during handling of the above [aiohttp] exception...") which does gives you the result that 'the url is bad' for you, it just seems that there's a bug in the exception handler (?)

#

here's the traceback

📎 message.txt

warm oar Jun 22, 2024, 1:38 PM

#

forget that, i am on massive autopilot rn

#

@eternal hearth ill have a look at the hikari one, but for you, you should look at ```py
File "C:\Users\TheCreatorrrr\AppData\Local\Programs\Python\Python311\Lib\socket.py", line 962, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
socket.gaierror: [Errno 11001] getaddrinfo failed

#

thats your real error

#

btw, this would normally raise aiohttp.client_exceptions.ClientConnectorError

eternal hearth Jun 22, 2024, 1:51 PM

#

warm oar thats your real error

i'm not sure what i can do about that error since it seems to originate from hikari or arc, the socket.gaierror is no longer there for my code to intervene

warm oar Jun 22, 2024, 1:51 PM

#

nono, i spooted it wrong

#

the one that will be raise to you (after i fixed this greatly spotted bug btw) should be the aiohttp.client_exceptions.ClientConnectorError you see in the traceback

#

@eternal hearth https://github.com/hikari-py/hikari/pull/1946 should fix it

GitHub

Fix incorrect cleanup when failing to create request with a web rea...

Summary
Fix incorrect cleanup when failing to create request with a web reader
Checklist

I have run nox and all the pipelines have passed.
I have made unittests according to the code I have add...

#

pip install git+https://github.com/davfsa/hikari@bugfix/incorrect-web-reader-closure

if you want to test it out

#

lmk if everything is sorted :)

eternal hearth Jun 22, 2024, 2:22 PM

#

warm oar lmk if everything is sorted :)

uhh there seems to be another issue, now there's a BadRequestError when i try to respond to the interaction again, also there's another (very simillar) BadRequestError on shutdown now: hikari.errors.BadRequestError: Bad Request 400: (40060) 'Interaction has already been acknowledged.' for https://discord.com/api/v10/interactions/......(blah blah blah)
I tried:

try:
  await ctx.respond(attachment=hikari.URL('https://sdfgfksfgjskfhjgksdfhjgksdgsdfgsd.com'))
except Exception as e: 
  c(f'caught {tcr.extract_error(e)}')
  # if i try to respond here a BadRequestError is raised.```
There seems to be a `hikari.HTTPError` which i can catch now (nothing wrong here)
But there are to be two `hikari.BadRequestError`s now after the retrying for `ClientConnectorError` ends unsuccessfully

The '❌ Something went wrong contact the bot developer' seems to be given out immediately once first ClientConnectorError is raised (as opposted to what i'd think should happen: keep retrying until out of retries, only then tell thet user of an error)

What i think is happening is that the ctx.respond is trying to create an initial response but due to the previously triggered '❌ Something went wrong...' it can't, i'm only wondering why is it that ❌ gets triggered, the `ClientConnectorError` seems to be handled?

#

#

(the purple print is where i call c())

warm oar Jun 22, 2024, 2:27 PM

#

The '❌ Something went wrong contact the bot developer' seems to be given out immediately once first ClientConnectorError is raised (as opposted to what i'd think should happen: keep retrying until out of retries, only then tell thet user of an error)

I assume the "Something went wrong contact the bot developer" is an arc thing, and just from logic, they should not be able to handle anything, so its impossible that they are seeing the ClientConnectorError. It does make me think that its due to you not having enough time to respond (just from the backoffs alone, you are exceeding 3s, which you need to respond as specified by Discord)

What i think is happening is that the ctx.respond is trying to create an initial response but due to the previously triggered '❌ Something went wrong...' it can't, i'm only wondering why is it that ❌ gets triggered, the ClientConnectorError seems to be handled?
@winged dirge thats you. I havent looked into it, but its your lib :P

#

and the final error is also something for hyper to look at (seems to do with the autodefer)

winged dirge Jun 22, 2024, 2:28 PM

#

eternal hearth uhh there seems to be another issue, now there's a `BadRequestError` when i try ...

uhm

#

if you get a "Something went wrong" that means an exception occured inside the command callback that you did not handle

#

it either wasn't caught

#

or you have no error handler handling it

#

you can disable this behaviour by making an empty error handler on the client

#

overriding this default behaviour

warm oar Jun 22, 2024, 2:29 PM

#

doesnt arc log the error when that happens?

winged dirge Jun 22, 2024, 2:30 PM

#

it does

warm oar Jun 22, 2024, 2:30 PM

#

then were in logs 🤔

winged dirge Jun 22, 2024, 2:30 PM

#

catThink

warm oar Jun 22, 2024, 2:30 PM

#

wait, no way discord did this

#

~~please dont tell me they did~~ nvm, thought they changed the error for responding too late

eternal hearth Jun 22, 2024, 2:31 PM

#

winged dirge if you get a "Something went wrong" that means an exception occured inside the c...

the thing is, that i can see the "❌ something went wrong" before i exit the handler, like, the print "caught HTTPError" happens after i can see in discord that the ❌ message has been delivered

winged dirge Jun 22, 2024, 2:31 PM

#

#

this is the impl

#

I just dump the traceback in stderr

#

just like python does

warm oar Jun 22, 2024, 2:32 PM

#

winged dirge

you know logging.error exists, right?

#

you should be using that

#

not a print

winged dirge Jun 22, 2024, 2:33 PM

#

warm oar you know logging.error exists, right?

but logging.error logs to an error thing

#

that's not what python tracebacks do

warm oar Jun 22, 2024, 2:33 PM

#

you can add the traceback too :P

winged dirge Jun 22, 2024, 2:33 PM

#

I try to make it work like how python works

warm oar Jun 22, 2024, 2:34 PM

#

@winged dirge adding the exec_info will make it work like python would

winged dirge Jun 22, 2024, 2:34 PM

#

catThink

#

noted

warm oar Jun 22, 2024, 2:34 PM

#

anyways

winged dirge Jun 22, 2024, 2:34 PM

#

but either way

#

it should not get lost

warm oar Jun 22, 2024, 2:34 PM

#

back to the thing at hand

#

where error

winged dirge Jun 22, 2024, 2:34 PM

#

unless you redirected stderr

#

and it is printed before the response is made

#

also the response silently fails if it cannot happen, as you can see

#

so it has no way to fuck up the traceback not being printed

#

the only thing that can potentially happen is that the response deadlocks the bot or smth, but then that would happen after the traceback is already printed

warm oar Jun 22, 2024, 2:36 PM

#

@eternal hearth would you be able to provide the full code you used?

warm oar Jun 22, 2024, 2:36 PM

#

eternal hearth uhh there seems to be another issue, now there's a `BadRequestError` when i try ...

basically the context to this one

winged dirge Jun 22, 2024, 2:36 PM

#

yeah if you can give me a minimally reproducible example then I can take a look

eternal hearth Jun 22, 2024, 2:36 PM

#

warm oar <@507642999992352779> would you be able to provide the full code you used?

sure, gimmie a sec

winged dirge Jun 22, 2024, 2:37 PM

#

winged dirge

and also if you have an error handler that doesn't re-raise an error itself, it should just pass the exc to that

#

and not use the default impl

eternal hearth Jun 22, 2024, 2:38 PM

#

https://github.com/anamoyee/RoboBottom, the whole code is here, the relevant part is in src/r13_slash.py at the bottom of the file

warm oar Jun 22, 2024, 2:40 PM

#

@eternal hearth fyi, you can replace hikari's banner with your own one instead of using other stuff https://github.com/anamoyee/RoboBottom/commit/1ad90e1155da38b582ec458bf79627d7ece7a1b4#diff-30bceaf92e6f060702d21fd47f4d537826c4576c95ad790752b44193d9b861c2

#

https://github.com/hikari-py/hikari/blob/master/hikari/banner.txt and then pass banner="yourpackagename" and hikari will grab it and use it

#

just a random thing

winged dirge Jun 22, 2024, 2:42 PM

#

I have to say, this is quite cursed

#

you should just use hooks to check these (dev_only_cmd) instead

#

catThink

#

https://arc.hypergonial.com/guides/hooks/

Hooks - hikari-arc documentation

A guide on how to use hooks in arc

eternal hearth Jun 22, 2024, 2:43 PM

#

warm oar <@507642999992352779> fyi, you can replace hikari's banner with your own one ins...

i wanted to have both, also my banner uses eval for colors idk how colors are done in hikari

warm oar Jun 22, 2024, 2:43 PM

#

why eval catThink

#

we just replace parts of the banner with colour markers depending on whether colours are enabled or not

#

eternal hearth Jun 22, 2024, 2:44 PM

#

the banner file is:
{color1}sometext{color2}someothertext

warm oar Jun 22, 2024, 2:44 PM

#

warm oar

:P

#

there are ways to replace it without using eval

eternal hearth Jun 22, 2024, 2:45 PM

#

eternal hearth the banner file is: {color1}sometext{color2}someothertext

well not exactly this but simillar, and i just provide a dict of colors to eval's locals or sth

warm oar Jun 22, 2024, 2:45 PM

#

https://github.com/hikari-py/hikari/blob/master/hikari/internal/ux.py#L294-L323 how we do it in hikari

eternal hearth Jun 22, 2024, 2:47 PM

#

winged dirge you should just use hooks to check these (dev_only_cmd) instead

i think i made theese before i knew hooks existed or didn't bother to learn how they worked and it just stuck with me somehow ¯_(ツ)_/¯

warm oar Jun 22, 2024, 2:49 PM

#

ill let hyper help you with this, idk what is wrong :)

eternal hearth Jun 22, 2024, 2:52 PM

#

winged dirge

i have no idea how this thing responds without printing

winged dirge Jun 22, 2024, 2:59 PM

#

.remind 30m

unique finch Jun 22, 2024, 3:06 PM

#

I love the hikari banner file, its beautiful. it looks italic lmao

warm oar Jun 22, 2024, 3:06 PM

#

lmao

unique finch Jun 22, 2024, 3:06 PM

#

hikari

shadow badgeBOT Jun 22, 2024, 3:29 PM

#

@winged dirge: Reminder!

No Message.

Original Message

[Jump](#1254066636290396221 message)

winged dirge Jun 22, 2024, 3:31 PM

#

eternal hearth i have no idea how this thing responds without printing

hmmpf

#

that's odd, lol

#

what happens if you remove the try/catch

#

and just try to respond

eternal hearth Jun 22, 2024, 3:42 PM

#

winged dirge what happens if you remove the try/catch

nothing changes except after all the retries fail there's an additional hikari.HTTPError

winged dirge Jun 22, 2024, 3:43 PM

#

odd

#

but you do get the traceback eventually

#

just.. later

#

catThink

eternal hearth Jun 22, 2024, 3:48 PM

#

like, i am getting the traceback later just because on shutdown an asyncio task notices it was never retrieved

#

it looks like the bad request itself is done when the command exits

#

wait what

#

why would it do anything if command finished successfully (all errors would've been caught by the bare except in this case there)

warm oar Jun 22, 2024, 3:54 PM

#

that exception is raised by the autodefer

#

its doing something weird

#

@winged dirge

winged dirge Jun 22, 2024, 3:54 PM

#

catThink

eternal hearth Jun 22, 2024, 3:54 PM

#

eternal hearth why would it do anything if command finished successfully (all errors would've b...

it only shows seconds so i can't see the exact timestamp it could be a bit earlier or a bit later

winged dirge Jun 22, 2024, 3:54 PM

#

but autodefer should not happen if you do ctx.respond beforehand

warm oar Jun 22, 2024, 3:54 PM

#

what arc version do you have?

winged dirge Jun 22, 2024, 3:54 PM

#

also a good question

warm oar Jun 22, 2024, 3:55 PM

#

winged dirge but autodefer should not happen if you do ctx.respond beforehand

ik

#

but this is weird already

winged dirge Jun 22, 2024, 3:55 PM

#

like I use a lock on ctx.respond to ensure autodefer cannot hijack a response in progress

#

or vice-versa

eternal hearth Jun 22, 2024, 3:55 PM

#

warm oar what arc version do you have?

1.3.4, i updated before making this thread

winged dirge Jun 22, 2024, 3:55 PM

#

can you narrow this down to a minimally reproducible example

#

like a bot with 1 command

#

that still has this issue

#

I'll take a look on my end & see what arc is doing

eternal hearth Jun 22, 2024, 4:00 PM

#

sure

eternal hearth Jun 22, 2024, 5:04 PM

#

okay, it looks like i fixed it (i think the issue was on my side), thanks for help

#responding to a slash command with attachment=hikari.URL(<invalid url>) causes some issues