Major: Redoing the entire approach, architecture teardown, questioning whether the code review should even exist
You want to avoid talking about minor issues as these should be caught via automation with linters.
While major issues should definitely be called out on a code review (better late than never), these problems should have been caught prior to the code was written during the technical design and overall planning phase for the project. If you find yourself doing this, you should zoom out and question if the team has the proper processes in place to proactively write good code instead of reactively preventing it from getting merged in at the last minute.
Some examples of good code review discussion:
Calling out an uncovered edge case
Suggesting a more descriptive name for a class or method
Modularizing the code by making a common interface or utility method