How do you check if the wheel exists before accidentally reinventing it?

I've been running into this problem where I keep building components that have already been built. To give some context, I'm currently working on a new microservice replacing functionality in a monolith. I'm currently the only developer dedicated to this project 100% of the time; someone already did the bulk of the foundational work, and another developer added a few components, the rest of the project is on me.

One of the problems is that the components that exist in the monolith are confusingly named, and part of the effort is to give everything more meaningful and clear names in the new microservice. This is a great idea and everything, but it's causing me to build things that are already there; I don't realize they already exist because I am not sure what kind of terms I should be grepping the code base for.

For example, I need to make a service that returns metadata about a certain class of objects. This class in the old system is called CatalogInfo, which is not very descriptive of what it is, so I decided it would be called ProductMetadata in the new system. I built out the contracts, models, and services for my new ProductMetadata component, only to have my pull request rejected because this has already been built, it's called VendorDescription.

This is extremely frustrating because I spent three or four days building out this component. I did global-searches for instances of all the combinations of "product," "catalog," "info," and "metadata" I could think of and got no results. I also grepped for some of the method names from the old system to see if they were yet migrated to the new system and nothing.

This has happened to me twice now, and I feel really, really stupid for it. I feel like the only way to avoid doing this again is to either read through every line of code that already exists (this might be doable at this stage since it's still a newer system) or schedule a 1-on-1 with the last two developers before starting any work. Besides these things, are there any known patterns or techniques for not making this mistake in the future?