Seems Binance Smart Chain Testnet is no longer working for swapping. I'd usually switch to testnet and use Bakeryswap to test liquidity and swapping but it gives an error currently that says "execution reverted: BakerySwapRouter: EXPIRED". I am curious to know if anyone else is experiencing this.
Related
I'm following the instructions off the book Mastering Ethereum, (https://www.onlineprogrammingbooks.com/mastering-ethereum/) and I've hit a snag.
I've set up the MetaMask extension and trying to make the first transaction via the Ropsten network. I'm getting the error:
{"error":"[ethjs-query] while formatting outputs from RPC '{\"value\":{\"code\":-32000,\"message\":\"replacement transaction underpriced\"}}'"}
MetaMask is set up on Brave. I've tried with and without VPN.
I got this error as well:
{"error":"[ethjs-query] while formatting outputs from RPC '{\"value\":{\"code\":-32000,\"message\":\"replacement transaction underpriced\"}}'"}
For me, I turned off my adblocker and it worked.
I tried again a few days later and it just worked. It might have been a problem with my VPN after all.
I am trying to follow the following example with no luck.
https://googlechrome.github.io/samples/web-bluetooth/automatic-reconnect.html
The promise that is returned by the connect function never resolves. The example appears to imply that if a connection can't be made it should throw an error but this does not occur.
My app was rejected today due to 'not supporting IPv6'. I've attached screenshots of the error they received which comes from a Parse.com API call.
I could really use some help on this, as I have no clue where to start with this.
Does anyone know if Parse.com supports IPv6? Or do I need to add something to my code? Do I need to migrate to Parse Server?
Please help =\
---- EDIT ---- 9/22/16
OK so, after my first rejection due to "IPv6" issues, I re-submitted and the app was approved. I'd still like to understand if Parse.com and Parse Server are officially IPv6 compatible but as for now, I'm just happy my app was approved. I'll keep this thread open and will edit it when I find the answer.
I have a parse server hosted on Heroku which doesn't support IPv6 yet (see here). But your server is not the reason why the app is rejected. It is your app which should support IPv6.
A possible solution is to download the latest Parse framework from https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/releases/tag/1.14.2 and replace the old ones. I think it should work.
Below is my comparison with the logs in the console for my app with the two different versions of Parse framework.
I have used Parse.framework and Bolts.framework from Feb 2016 in my Apple TV app and also just got rejected also for not supporting IPv6. I checked the log and found that
nw_resolver_start_crazy_eyeballs_timer Received IPv4 result first, performing crazy eyeballs: waiting 50ms on IPv6 for myapp.herokuapp.com:0.
__nw_resolver_start_crazy_eyeballs_timer_block_invoke Crazy eyeballs timer fired: did not receive IPv6 in time, reporting only IPv4 result for myapp.herokuapp.com:0
nw_resolver_cancel_crazy_eyeballs_timer Cancelling crazy eyeballs timer for myapp.herokuapp.com".
It seems the performance issue comes from the 50ms when the app loads.
I use the latest Parse framework and no "crazy_eyeballs_timer" shows up. The log seems more promising because I can see a IPv6 address in the log now.
nw_resolver_create_dns_service_on_queue Starting host resolution myapp.herokuapp.com:0, flags 0x4000d000
nw_resolver_host_resolve_callback flags=0x3 ifindex=0 error=NoSuchRecord(-65554) hostname=myapp.herokuapp.com. addr=0.0.0.0:0 ttl=60
nw_resolver_host_resolve_callback flags=0x2 ifindex=0 error=NoError(0) hostname=us-east-1-a.route.herokuapp.com. addr=88:ffff::bbbb:afb9.0 ttl=74
Here I changed the addr of my server in the log for security reason.
I will send a new update of my app to review and I believe that it should work. I will leave a comment when it gets accepted :)
We stopped being able to connect to the feedback.sandbox.push.apple.com about two days ago right in the middle of testing. I checked the certificate and it is valid. I also ran the openssl troubleshooting commands... and it all appeared ok. But we also can NOT doing any testing or work against the sandbox APNS. We are getting the following error about a malformed message response when we try and create the SSLStream connection. I have been scratching my head for a day now... thinking it was something on our end... so would really appreciate a response if others are able to test and connect to the sandbox APNS using PushSharp current version 2.1.2 ??
A call to SSPI failed, see Inner exception" Inner Exception -> "The message received was unexpected or badly formatted."
We were having the same issue using the now deprecated APNS-Sharp library (ancestor to PushSharp). I submitted a pull request for APNS-Sharp that fixes the issue based on my tests.
See https://stackoverflow.com/a/23121258/3542341
and for the pull request: https://github.com/Redth/PushSharp/pull/369/files
I am working in an environment where we get production issues from time to time related to Oracle connections. We use ODP.NET from ASP.NET applications, and we suspect the firewall closes connections that have been in the connection pool too long.
Sometimes we get an "ORA-12571: TNS packet writer failure" error, and sometimes we get "ORA-03135: connection lost contact."
I was wondering if someone has run into this and/or has an understanding of the difference between the 2 errors.
Using a mobile phone analogy:
ORA-12571 (Failure) Means call is dropped.
ORA-03135 (Connection Lost) Other party hung up.
My understanding is that 3135 occurs when a connection is lost. This doesn't tell you why the connection was lost, though. It may have been terminated by the server because the server failed to recieve a response to a probe for a certain amount of time, and assumed that the connection was dead. Or (I'm not sure about this) the exact reverse of that: the client failed to recieve a probe response from the server for a certain amount of time, so it assumed the connection was lost. The "certain amount of time" is cotrolled by SQLNET.EXPIRE_TIME=[minutes] in sqlnet.ora.
As for 12571, my (again vague) understanding is that there was a sudden failure to send a packet during communication with the server, and that this is typically caused by some software or hardware interfering with the connection (either by design, or by error). For instance, if you pull out your ethernet cable and then try to execute a query, you'll probably get this. Or if a firewall or anti-malware application decides to block the traffic.