Generally the person who runs into the conflict also has to resolve it, after all it's the person who wants that merge to happen and resolving the conflict is required to make it happen.
In your sample that would be person A. It's person A who wants his code in the master branch. It's not person B who wants that code there. Person B just made changes to the branch and apparently they didn't conflict or if they did, he resolved the conflict. Assume person B had been much faster adding his changes, then person A would have had to deal with them already on his feature branch, wouldn't he? Well, now person A has do deal with them afterwards, which should just be a little bit of extra work.
If it is a lot of extra work as the conflict is huge, something went wrong completely. E.g. if two people implemented the same feature or contradicting features or one person worked on a feature while another one completely restructured the project, then there was some planing/management deficit in the preparation of these two code changes.
In that case, you need to discuss if resolving that conflict is even meaningful at all. Sometimes it just makes more sense to discard one of both changes completely (which one has to be discussed) and redo the work on the new code base because solving the conflict would be at least an equal amount of work. Sometimes another change may even make a feature obsolete or require it to work completely different manner as it has been designed. In that case merging alone will not get you anywhere, as you will still have to make a huge amount of extra adoptions after the merge and these alone may equal the work to re-implement that feature on the new code base from scratch.
As a general development tip:
If you have a long running feature branch, keep merging the master branch into that feature branch on a regular basis. This prevents the two branches from developing too far apart and makes the final merge much easier. Also you will quickly see if there is something going on on the master branch that will conflict with the way how you intend to implement that feature. It's then up to you to stop the people who currently mess with the master branch and discuss how to proceed with that situation, or to just adopt your implementation strategy to their changes.
An example for the later case: You planned to make it synchronous, they currently make everything asynchronous on the master branch, then you should also implement that feature asynchronously following the same pattern that they use. By merging their changes into your feature branch, you may even have some new, useful methods available that they added to the master branch and that makes it much easier for you to now implement your planned feature in an asynchronous fashion. If you had just focused on the feature branch, your feature will be done one day and it will be synchronous, then you try to merge it, just to find out, that everything in the project has changed and even if you can resolve that merge conflict, it won't buy you a lot as you will still have to make your feature asynchronous now and that may as well equal rewriting it from scratch.