additional error handling

[Keyrxng]

Relates to #13

I'm debugging in the dark here because

1. My cf webhook url now sets instantly for me but not the ubiquity one
2. I can't see cloudflare logs. If I can get access scoped to this worker (and the kernel would be good) that would be great.
3. I'm guessing at what's happening between the kernel and worker
4. Things work smoothly for me, I'm making assumptions which is why I'm adding more error handling for whoever needs to read the cloudflare logs for me

Notifications working for me and the CF log for the notification which succeeded:

I'll continue to just debug in the dark until it's working it can only be a few reasons I'm thinking but my life would be easier and development of this plugin faster if I had the correct access.

[Keyrxng]

#17 (comment)

The MTProto side of things is working as intended which uses actions and repo/org secrets

The TG bot seems to not be responding idk if that's worker env var related or something, could you check for me when you can please @0x4007 @gentlementlegen

It should have APP_ID, APP_PRIVATE_KEY and TELEGRAM_BOT_ENV. I'm sure the workflow uploads the required secrets so I'm unsure because I'd expect workrooms to be down too so it might be worker env

[gentlementlegen]

That's all the detail about the error

[Keyrxng]

I spent a couple hours last night after I got access comparing my worker logs to the ubiquity worker' when setting the webhook (that was my main focus) and trying to find more info on it in their docs/forums etc

I'm going to merge the debug changes I made locally last night, deploy the worker and compare again. I expect to have it put away today.

I set webhook to my worker url and get no cf log. I send /botid and 1st req cancelled always. TG auto-retries the failed req and I get a response on TG. All within 5s this was happening, the first time it's had no delay since I started building.