Responsibilities of the Repository pattern, how best to organize the code?

Question

C++ / C#

Suppose we have a table with users Users.
The user has an end date for his work in the system (ExpirationDate).

There is a table with notifications for users UserNotifications.
The notification has a field with a type (TypeId).

There is a class (separate application) that every day looks for users who have their term of service in the system expires in a month and creates a notification of a certain type for such users (let it be TypeId = 1).
Eg. "Your period of work in the system ends on 01.07.21..."

Accordingly, the following logic should be done by this class --

Find all users whose term of work will end in a month.
Create a notification for them, ONLY if the user does not have a notification with this type yet.

If I understand correctly, there may be approximately the following solutions:

Option 1:
1) Using the UserRepository method, find all users whose ExpirationDate ends in a month.
2) Using the UserNotificationRepository method, find out if there is already a notification with this type in the database for this user.
3) If there is no such notification => create it using the UserNotificationRepository

2 method Option:
1) In the UserNotificationRepository method (or the UserRepository method?), use one request to find those users whose ExpirationDate ends in a month + in the database for this user there is no notification with such type.
2) create it with UserNotificationRepository method

-------------

I like the 1st option more from an architectural point of view - each repository is responsible for its direct duties, business logic is not involved in them ... the minus is that you have to load those users from the database from the database for whom there is already a notification, and only then filter them...

Option 2 is better in terms of performance - we immediately get the right users.
But, it is somehow more clumsy from the point of view of architecture, as it seems to me.

What would you do?

Answer 1

If an entityframework is used, then I would make a service that receives a dbcontext in the constructor and additionally does not fence anything. Because DbContext is already UnitOfWork with repositories inside.