-
Notifications
You must be signed in to change notification settings - Fork 29
Release 1.9 breakes previously running code #39
Comments
Hi @ValentinsStorre Thanks for using the library. It's very normal that anyone's code needs to be rechecked or modified a little bit, if necessary, after updating any library. That's why a new version is created, with added features, functions, etc. Moreover, as you're using ESP8266, you can use asyncHTTPrequest library, if better for you. Good Luck I retest using ESP8266, and see nothing abnormal here
|
I am sorry, I was a bit lazy and had not attached any debug log. I thought the problem was somewhat obvious. Version 1.8.2.
Version 1.9.1.
As I already said: It seems like the readyState is set incorrecty to readyStateDone early in the toolchain.
This is not a problem of backward compatibility with my code. The library has obviously some kind of glitch, which can't be intended. There is nothing I can fix on my side, to change that issue without messing with the library source code. |
Hi @ValentinsStorre Please try the new AsyncHTTPRequest_Generic v1.10.1. Your contribution is noted in Contributions and Thanks Releases v1.10.1
|
### Release v1.2.1 1. Fix bug of wrong `reqStates`. Check [Release 1.9 breakes previously running code #39](khoih-prog/AsyncHTTPRequest_Generic#39) and [Callback behaviour is buggy (ESP8266) #43](khoih-prog/AsyncHTTPRequest_Generic#43) 2. Optional larger `DEFAULT_RX_TIMEOUT` from default 3s, for slower networks
### Release v1.2.1 1. Fix bug of wrong `reqStates`. Check [Release 1.9 breakes previously running code #39](khoih-prog/AsyncHTTPRequest_Generic#39) and [Callback behaviour is buggy (ESP8266) #43](khoih-prog/AsyncHTTPRequest_Generic#43) 2. Optional larger `DEFAULT_RX_TIMEOUT` from default 3s, for slower networks
### Release v1.2.1 1. Fix bug of wrong `reqStates`. Check [Release 1.9 breakes previously running code #39](khoih-prog/AsyncHTTPRequest_Generic#39) and [Callback behaviour is buggy (ESP8266) #43](khoih-prog/AsyncHTTPRequest_Generic#43) 2. Optional larger `DEFAULT_RX_TIMEOUT` from default 3s, for slower networks
### Releases v1.4.1 1. Fix bug of wrong `reqStates`. Check [Release 1.9 breakes previously running code #39](khoih-prog/AsyncHTTPRequest_Generic#39) and [Callback behaviour is buggy (ESP8266) #43](khoih-prog/AsyncHTTPRequest_Generic#43) 2. Optional larger `DEFAULT_RX_TIMEOUT` from default 3s, for slower networks
### Releases v1.4.1 1. Fix bug of wrong `reqStates`. Check [Release 1.9 breakes previously running code #39](khoih-prog/AsyncHTTPRequest_Generic#39) and [Callback behaviour is buggy (ESP8266) #43](khoih-prog/AsyncHTTPRequest_Generic#43) 2. Optional larger `DEFAULT_RX_TIMEOUT` from default 3s, for slower networks
### Release v1.9.1 1. Fix bug of wrong `reqStates`. Check [Release 1.9 breakes previously running code #39](khoih-prog/AsyncHTTPRequest_Generic#39) and [Callback behaviour is buggy (ESP8266) #43](khoih-prog/AsyncHTTPRequest_Generic#43) 2. Optional larger `DEFAULT_RX_TIMEOUT` from default 3s, for slower networks
### Release v1.9.1 1. Fix bug of wrong `reqStates`. Check [Release 1.9 breakes previously running code #39](khoih-prog/AsyncHTTPRequest_Generic#39) and [Callback behaviour is buggy (ESP8266) #43](khoih-prog/AsyncHTTPRequest_Generic#43). 2. Optional larger `DEFAULT_RX_TIMEOUT` from default 3s, for slower networks
### Release v1.9.1 1. Fix bug of wrong `reqStates`. Check [Release 1.9 breakes previously running code #39](khoih-prog/AsyncHTTPRequest_Generic#39) and [Callback behaviour is buggy (ESP8266) #43](khoih-prog/AsyncHTTPRequest_Generic#43). 2. Optional larger `DEFAULT_RX_TIMEOUT` from default 3s, for slower networks
### Release v1.9.1 1. Fix bug of wrong `reqStates`. Check [Release 1.9 breakes previously running code #39](khoih-prog/AsyncHTTPRequest_Generic#39) and [Callback behaviour is buggy (ESP8266) #43](khoih-prog/AsyncHTTPRequest_Generic#43). 2. Optional larger `DEFAULT_RX_TIMEOUT` from default 3s, for slower networks
On ESP8266:
After updating from 1.8.2 to 1.9.1 my code shows some unexpected behaviour:
The code compilies and runs without crashing but some sequencing seems to be messed up. The request callback seems to be called before sending and the readyState is set to readyStateDone incorrecty. Later the request callback is called again with the actual http request, which seems to have worked annyway. I am guessing the readyState is set incorrecty to readyStateDone somewhere early in the toolchain, which seems to trigger unexpected behaviour.
The text was updated successfully, but these errors were encountered: