After signing into Transporter get the error message below.
"Can't authorize your user at this time. This action could not be completed due to possible environment mismatch (-29004)"
I have tried all the fixes mentioned here for similar errors and on the apple support forum but none work for me.
Any advice would be great.
Have logged a support ticket with apple dev waiting for a reply, I'm interested if others are experiencing this error with Transporter.
Apple mini M1 2020
macOS Monterey
Ver. 12.5
Related
I face a somewhat weird problem. Unfortunately, I have to diagnose and repair it from distance without any real access. So I don't know if I can provide enough information to solve it.
Context:
I built an interface for my grandma (94) to chat with the family via telegram by connecting a Telegram bot to a microphone (for her to record voice messages) and a small printer (for the messages to be printed for her). [This is inspired by the Yayagram invented!]
The problem:
For the last one year, everything worked just fine. However, a few days ago, the bot stopped working. My grandma could not send any voice messages and didn't receive any of our messages. After calling her and checking all the connections, we restarted the device. Now, she can send voice messages, but the bot still doesn't process our text messages (nor commands!).
I have never encountered a bot being able to send messages without processing incoming messages. As I said, I have no way to analyze the problem in detail as my grandma lives 500km from me. If anybody has any ideas where the problem could be, I would be very happy.
Edit:
I knew it would work to post a question on StackOverflow! Out of nowhere, the bot seems to work again. I have no idea what caused it, or why it started again as I did nothing. I am still grateful for any insight for what might have caused it!
I have a weird problem. I have an application (a bot) sending messages back to the user. The messages are generally (but may be not) equipped with a keyboard (reply_markup=ReplyKeboardMarkup) on which the user chooses the next option. The application is based on Ubuntu 14.04 > Tomcat 5 > Coldfusion 16 > Telegram bot API 4. Everything has been working as a breeze (and it still does!).
Since I want to upgrade my aged server, I have been struggling on many recipes of server (Ubuntu 18.04 LTS or 20.04 LTS), Coldfusion (16 , 18, as well as Lucee, Openbluedragon) . It seems that Telegram bot API 5 are on line, I cannot choose.
The problem is that SendMessage equipped with reply_markup result in a 500 error, wilst the same message without the keyboard is accepted and sent smoothly. The keyboard has been carved to the bone, such as :
mykeyboard='{"keyboard":[["A","B"]],"one_time_keyboard":"true"} '
I have tried GET or POST methods in HTTP. I could understand some difference in migration from API 4 to API 5, but the very same API 5 keeps working with my application on the production server... headache. Can anybody show me a way to understand? Thank you
After the long puzzle, here's the answer. It seems that in API 5, in the definition of a keyboard, the
"one_time_keyboard"
clause is no longer supported. Just tease it away:
mykeyboard='{"keyboard":[["A","B"]]} '
and it will run again
:-(
I can't get my bot approved on Kik because of the following reason:
Your bot failed to respond to messages of the following types: start-chatting, video
I'll probably fix the start-chatting, but the video part is weird.
In other channels (e.g. Facebook Messenger) my bot intercept the video and can responds to it, but on Kik, it seems like I get no message at all when the user sends a video message.
Anyone familiar with that issue? Any help would be appreciated.
I'm using the Node.Js SDK.
I solved it. My bot service is running on Azure, and after 20 minutes of inactivity, the server is becoming idle and the response is delayed in about 15 seconds.
We're using the Direct Line 3.0 API to performance test our Microsoft Bot Framework bots that are written in NodeJS. Regardless of load, we get intermittent timeouts in our harness while waiting for activities we expect to come back. These coincide with issues being reported for the bot at dev.botframework.com. They look like this:
That message doesn't make it clear what error has been experienced sending a message to us.
Our server-side and client-side are not reporting any errors, as far as I can tell, we are always responding with 20x statuses, and I can only assume the error is happening somewhere between the bot framework and our services. How can I find out what error is causing the error sending the message, or what status code it thinks it has received?
I have Pusher integrated into my web app. It's a Java based app running on Windows server 2008. The Pusher Server library is the one available on their website.
I've been using Pusher on my development machine and staging machine with no problem. I only use public channels, and only 2 public channels (an admin channel and an "other user" channel. Everything works as expected when my application is deployed to dev or staging servers.
Errors start occurring when I push to production though. I continually get 401 errors, like Pusher isn't authenticating my credentials. This is despite the fact that the credentials between dev/staging/prod are exactly the same, and the code is unchanged.
Am I missing some setting? Firewall setting? Is Pusher caching some information I don't know about? I'm at a loss about where the problem could lie.
To prove the error is specifically on the production server only, I can log in as an "other user" against the production machine (loading the Pusher client code), then fire an event as an admin on my development machine (loading the Pusher server code) and it works. When I fire the same admin event from my production machine, that's when the 401 errors occur.
Server returned HTTP response code: 401 for URL: http://api.pusherapp.com/apps/....
Found this after digging around a while. My system time was off by an hour on the production server, which gave the error from Pusher, and explains why it worked fine on dev and staging but failed on production with exactly the same code.