-
Notifications
You must be signed in to change notification settings - Fork 0
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
Debug invoice_lines_from_invoices task #1259
Comments
The log error might be related to something else and not necessarily the invoice_lines_from_invoices task. I cleared out my local digital_bookplates table and ran the fetch_digital_bookplates dag and one of the add_update_model mapped tasks failed with a folio_client error:
|
I'm thinking it may be a timeout issue with Okapi call, looking at the FolioClient source code, we can set an environmental variable |
I think this error may stem from a problem with the folio-dev Okapi handling of HTTP connection pooling being established by the folio_client's underlying httpx package (see this comment). Running the |
I deployed to airflow-dev and the same task fails in the same way with folio-test. It got about a 3rd of the way through the list of invoice-lines and failed, restarting the whole task (iterating through the list again). I guess I will try to set the FOLIOCLIENT_HTTP_TIMEOUT to a larger setting. Although, we might see the problem again because of what you found about the server dropping the connection. |
Re-running the fetch digital bookplates dag on airflow dev, one of the bookplates failed on the first attempt to get the folio fund uuid with the same error:
It succeeded on the second attempt. |
@jermnelson I re-read that comment on httpx and I am wondering if there is a problem with this line of code in FolioClient: https://github.com/FOLIO-FSE/FolioClient/blob/034431fa586e787a487ab402446631e49ec701df/folioclient/FolioClient.py#L360 basically, when the httpx_client.is_closed, it returns the exception. Should the FolioClient retry reopening the transport connection instead? (I'm thinking about this RFC quoted from the httpx issue comment):
Or should we be doing a retry ourselves when handling the client? Or just leave Airflow to do the retries? |
Looking at the stacktrace, the error is occurring when the FolioClient is trying to authenticate and before making any |
I'm going to move this ticket to Ready since we are not yet actively addressing the issue. We can always "clear task" when it fails the number of retries. We might see more issues as we test the add 979 tag DAG. |
When running the digital_bookplate_instances DAG locally with okapi-dev as folio, it fails on the invoice_lines_from_invoices_task. The error in the log shows:
In looking at the logs for okapi, mod-invoice, and mod-invoice-storage, I see in okapi there are 2 requests for the invoice ID that stopped everything (the second GET is probably the airflow task retry):
In the mod-invoice, these 2 requests (request ID's 348159 and 939406) appear as:
And only request ID 348159 has a response (16s later):
The response contains "totalRecords":598 and includes all the invoice lines for all the invoices that are queried. So I'm thinking the folio_client's
folio_get_all
works in some unexpected way.The text was updated successfully, but these errors were encountered: