devmadhuu commented on PR #9121: URL: https://github.com/apache/ozone/pull/9121#issuecomment-3382039569
> > For OpenKey, its valid scenario where path can not be constructed, and we must show those open keys, > > Why do we need to return the open keys? OM doesn't list open keys until they are committed by default. Those keys may or may not get committed, so I would suggest the listKeys should not include open keys at all. > > I am not really up to speed on the NsSummary database generation, but if the case is that only recently added keys can have a missing path, then it would be OK to skip them. The listKeys result is always lagging that from OM, and its constantly changing as the cluster adds / removes files. I think that is a better solution than just having a null path for a key sometimes. A key without its full path is fairly useless as it could belong anywhere on the filesystem. Just to add my understanding - listKeys API in recon doesn't include open keys, it provides only committed keys. Open keys listing is needed in Recon for observability, so yes possibility of missing full path can happen for either recently added keys not commited yet or all parts of multi upload key not commited yet (may be last part), So the reason , as rightly said, "`A key without its full path is fairly useless as it could belong anywhere on the filesystem.`", listKeys API is not including those keys which have empty full path. Sorry for jumping here, but just want to add my understanding as well. @sumitagrawl can add further. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
