master branch triggers an unhandled exception in EDAMErrorCode::RATE_LIMIT_REACHED exception handling #210
Comments
I sorted out that currently the rate limit reached is reset hourly on wall clock hour change, that is on every new hour of the day. So when the rate limit reached exception triggers and the rateLimitDuration attribute is not set, defaults to delay until the next hour. Fixes robert7#210
I sorted out that currently the rate limit reached is reset hourly on wall clock hour change, that is on every new hour of the day. So when the rate limit reached exception triggers and the rateLimitDuration attribute is not set, defaults to delay until the next hour. Fixes robert7#210
I sorted out that currently the rate limit reached is reset hourly on wall clock hour change, that is on every new hour of the day. So when the rate limit reached exception triggers and the rateLimitDuration attribute is not set, defaults to delay until the next hour. Fixes robert7#210
|
I found out I was not building "develop" branch from this git repository but I was testing the master branch. I have this issue on master fixed locally by adding code to set the delay to wait until the next wall clock hour is reached if the "rate limit reached" exception has its rateLimitDuration attribute not set (as I sorted out that as of now Evernote API reset the API limit reached every new hour of the day). My workaround for the master branch missing rateLimtDurataoin on the RATE_LIMIT_REACHED exception, which is not required because/if develop is merged to master: You might want to close this issue as it is not reproducible on the |
prahal
changed the title
|
@boo-yee I cannot see your comment on this issue, still answering. Also, the fix for the linked issue is to upgrade from nixnote2 2.0 to 2.1 in the latest PPA when this issue was reported (2019). Likely my issue has to do with qevercloud API changes. The non-handled exception triggered in the code to handle this rate limit exception, only the time to wait until the next attempt was not initialized. Running 2.1.10 (develop branch) 9c02e8a5 with a newer embedded qevercloud code fixes this bug (but the code is not in master yet). If the develop branch is not meant to be pushed to master soon, maybe it would be good for me to make a PR from the above patch I gave to emulate the time to wait until the next sync attempt, instead of the sync getting stuck in this unhandled exception forever (was stuck for days until I killed nixnote2 2.1.9 on my side). Note that with Debian nixnote2 2.1.9+dfsg1-1 I get a different backtrace because someway the rate limit reached exception code is not detected at all (while if I rebuild the master branch,ie 2.1.9-f9cbad25, I get the error I reported initially, after the same amount of time and the same load. So likely the same server error is triggering the issue. The Debian error I get is: |
|
just merged develop to master |
|
Thanks. Closing. |
Expected vs. actual behavior
Be able to retry sync once this specific rate limit exception has been triggered in the develop branch.
Nixnote2 still works after this unhandled exception but the sync button spins and I cannot stop the syncing to start a new one.
Steps to reproduce the problem (or log file)
this->minutesToNextSync = e.rateLimitDuration / 60 + 1;" raises anstd::exception was caught: qevercloud::Optional: nonexistent value access(from my debuge.rateLimitDurationisunsetwhen this exception triggers)Specifications
The
--logLevel=1output:this with debug code:
With the Debian nixnote2 package 2.1.9+dfsg1-1 I also had an exception but an handled one at the same stage (after around 25 minutes):
Somewhat the develop code (I believe with the QEverCloud upgrade) handles this error code properly (as a rate limit) but I don't know why this rate limit exception has no rateLimitDuration value.
Both Debian and develop branch has rateLimitDuration as EDAMSystemException field set as a qevercloud Optional.
Both have the RATE_LIMIT_REACHED EDAMErrorCode set as 19.
The fact that this field is not initialized looks like a bug in QEverCloud as the doc https://dev.evernote.com/doc/articles/rate_limits.php tells us to report this rateLimitDuration.
It could be that the error handling improved (in that the proper rate limit error is reported) but still has a bug (unset rateLimitDuration).
In the meantime, the code might check for the value to be set before accessing it.
Call
OptionalisSetorvalue(<default_value>)methods before accessing this rateLimitDuration attribute?qevercloud::Optional: nonexistent value access is triggered by access to an uninitialized Optional attribute in both Debian and develop branch of nixnote2.
I added debug output for the exception message attribute and it is also unset:
As an attempt workaround, I replaced:
by
It helps. The first ratelimit is followed 16 minutes afterward by a new successful sync until a new rate limit is triggered.
But after the second rate limit exception, the next sync attempt after 16 minutes (15 minutes from the #define above plus one added in the sync code to cope with the case where minutesToNextSYnc ends up as zero) fails immediately with a new rate limit exception. Afterwards, at times the sync works then after a while rate limit triggers, other times it aborts immediately with a rate limit exception. Maybe 30 minutes would be on the safer side, but I don't know if, at times, even more than 3à minutes would be required to always have the rate limit expired.
Still, the use of Optional value() is better than Optional isSet with which the time between sync attempts is always 1 minute.
The text was updated successfully, but these errors were encountered: