What the server should do depends on what the intended behavior is according to the business requirements. That is not something that a stranger on the internet can conclusively answer for your specific scenario.
By default, I would err on the side of breaking the request with a clear error message; simply because it could be cumbersome for the user to have to now fix their mistake using a new patch request; as opposed to simply fixing and firing the original request again.
But this is a default assumption on my part as a developer, made without any consideration for any particular business requirements or scenario.
Contextually, for a given business requirement or scenario, it could be perfectly okay that you only process the workable data and be done with it. However, it could also be reasonable to expect the end user to assume that a completed request means that the entire request has been serviced.
If you go with the approach of using what you can and ignoring what you can't use; you also have to decide how to communicate these non-breaking failures. These may come in the form of warnings returned to the user (with a success response), privately logging it, ... Again, you have to look at what your business requirements are and what makes sense to your specific scenario.