Closed planetf1 closed 4 years ago
Note that the UI does then allow searches to work correctly - at least of CSV assets @danielaotelea are you aware of this? Is it a problem for the 1.3 release?
I note that in AssetCatalogSupportedTypes.java there were no annotations - without these spring returns back a 500 without invoking our code. With the annotations added, I still get a 500, which is caused by hitting an exception in AssetCatalogRESTService.java:getSupportedTypes when setting the response - that was down to an incomplete mapping
@danielaotelea - I assume we take no action immediately for 1.3 here. This looks like new code, and the impact on the UI isn't critical. It's work in progress you'll presumably fix in 1.4? Fair?
cannot reproduce do you have any logs ?
Hi Nigel!
I'm not able to reproduce this issue.
I have added the annotations, but there is no problem on our current environment without that annotations.
Thanks...
I made the change to annotations locally - but it didn't help. I took your PR and built, but the same issue.
My environment is:
Note that without the fix I made for #2432 (now merged to master, in queue for release 1.3) Asset Catalog OMAS was not working AT ALL - and hence nor would asset search in the UI. With that fix at least the UI works, and searches are successful, so it's just a warning error at login time.
I will attach the error, but my simpler test case was just using httpie (or use curl)
The output I get when going to asset search in the UI is posted at https://gist.github.com/efcc3ae8b5588fec7e589c4d258d64cb
can you please provide also the configuration document for the server
can you please provide the response for getAllTypes
Hi!
I have added a check for the active types. Do you have a active types available? There are some repositories in the cohort?
the only way we reproduce it is for the case there are no types available on server.
but once again we do not have any logs we have 500 response but no logs
Apologies for the delay - calls, user issues & other 1.3 actions.
One method of reproducing is to run the coco pharma notebook environment - locally or in a container. Run the usual 'server configuration' and 'server start' notebooks, followed by 'asset-management/building a data catalog'. This reproduces the error every time.
The latest PR does stop the error. As you suspected, activeTypeDefs ends up being null --since the helper function looks up in the //local// repository, and in the coco environment the server cocoMDS4 is a member of the cohort, and is where the asset search UI is targetted at, but it does not have a repository of it's own. This is a perfectly valid configuration. We have many types, and a number of real assets -- and indeed even with this error, the UI is able to show search results (search for 'csv' for example)
As such the PR helps to mask the error, so may be worth merging, but there's a more fundamental change here needed so that the supported types can be queried properly.
This is one of the benefits of having the coco environment - consistency, and a typical 'enterprise' environment with multiple cohort numbers having differing roles.
But equally, running in other diverse configurations is important too so we can catch these kind of issues!
Asset Catalog OMAS, should return the known type defs from that service, instead of the active type defs. I need to replace the getActiveTypeDefs with knownTypdeDefs because the server may runs with OMASes configuration, but without a local repository. I open a new PR for that.
Thanks @danielaotelea will test that PR. From inspection looks good. It will be very useful to have this in 1.4 especially for the notebooks since we document asset catalog omas as new in 1.4
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.
This is fixed now and can be closed
The UI hits an exception on startup. The console logs (debug enabled) show:
Furthermore, an attempt to invoke this endpoint from the cli also fails with 500
Originally noted in #2426