Closed WadeBarnes closed 4 years ago
@ianco, I'm thinking the record limits we placed on the API may be causing the issue. It's difficult to tell because you see the request in nginx, but there is no sign of it in the API logs afterword.
Getting this same issue on my local, I'll dig into the query
(I mean it's rendering but it's taking a long time for this query)
3.4 MB for the returned json
This is related to the attributes being loaded for each related Topic for each relationship of the selected Topic.
Basically Pattison Inc (BC0928747) has 80+ related companies, and the query is pulling in all the attributes related to Pattison for every relationship. all attributes includes all attributes for the Topic and all related relationships, which includes all of the relationships (basically an exponential growth pattern).
I'm not familiar enough with the logic of how these queries are constructed, so have to reassign, I think to @cywolf but let me know if there is someone else who should look at this ticket.
I added an extra filter for the time being (restrict to only fetching attributes from Registration credentials) but needs review. The query is slightly faster but still very slow, and I'm not sure the fix I made is the correct approach.
This pull request in indy-catalyst (https://github.com/bcgov/indy-catalyst/pull/339) fixes the issue in the API. However, for this change to work the topic mapping in the services.yml also needs to change ( see this ).
Updating the topic mapping will require to re-issue the credentials, so this is why we currently have not ported the change over to TheOrgBook from ICOB.
@ianco @WadeBarnes what is the recommended course of action here? Asking you guys since you are the people who know and deal the most with re-issuing credentials.
Figure out why the response is slow and make it faster? :-)
Seriously, I believe that Ian had said something about a slow query that could be addressed. Is that the case here, or is this a condition that must be dealt with?
@swcurran see this. There is a code change we can port over (currently in ICOB), however it will require re-issuing all the credentials since it is a schema change (basically, the topic_id
needs to be scoped so that it can be filtered upon).
Things may work without reissuing the credentials (don't quote me on this though), but right now we would be filtering on registration
which is pretty generic and may pull in data from other credentials as well (imagine having a couple of different registration credentials for the same topic).
Btw, if we change the services.yml we will also need to tell the LCRB folks since they will need to update their mapping.
Got it. I'd say we do nothing about this and move forward with ICOB as quickly as possible. Is this holding anyone up, or just something we found?
I don't think it is holding anyone up, but it is definitely causing issues when querying for corps with a large number of relationships/credentials. If we are good with this while we focus on moving to ICOB I think we're good then.
Moving to done since we decided that are not going to tackle this in the "old" OrgBook.
Getting a Error 504 Gateway Time-out in the Credentials section for;
The following API call for the Org is the issue;
The corp has a long list of relations;
The issue does not occur on Corps with a smaller number of relationships.