-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ofxtools hanging on poor FI behavior #157
Comments
Yeah that is not the finest piece of production quality code I have ever written. Surely I can find a more refined algo for discriminating the header from the body. In other news, I may soon have need to become proficient in Go. How would you feel about rank novices clawing through your codebase and submitting ill conceived PRs riddled with obvious bugs? |
GO for it (haha heh ha ... ha?), that's half of what this "open source" stuff is all about. Just don't assume that you'll learn the most idiomatic Go from looking at my code... |
Another wrinkle: |
I'm not sure there's a better solution than this for neverending file descriptors, and it's simple to code. What I'm wrestling with is how to write the unit test. I haven't forgotten about this. |
I actually have a version of this locally and it "works", though its not as clean as might be ideal. I played around yesterday with trying to figure out if I could catch this condition higher in the call hierarchy (closer to where the request is made) but did not yet find a generic way to detect that the response was 0 bytes. |
I just hit this, pre-readline you should be able to cache to buffer position via |
I've seen ofxtools hang a few times (with different financial institutions), and when I Ctrl-C it, it is in the following loop:
ofxtools/ofxtools/header.py
Line 265 in 8455c43
This behavior seems to be transient (the same FI may not cause it on other days...). This is from a call to client.request_statements.
From adding some debug prints, it appears that the FIs in question are returning endless empty lines (lovely)
Maybe this could fail more gracefully (like a limit on the max number of iterations of this loop so it doesn't become infinite for poorly-behaved FIs)?
The text was updated successfully, but these errors were encountered: