Repository pattern with specific load type use cases

I'm trying to apply the repository pattern to an android app of mine and I'm having a hard time staying true to the definition of the pattern and keeping the type of persistence out of the business domain classes. Specifically, the problem is when I have 2 sources of data and I have valid use cases where I want to specify which one to load from.

A really simple and common example would be messages. Ideally my interface for the repo would look something like this:

interface MessagesRepo {
    List<Messages> get();

    void update(Message message);

    void delete(Message message);

    void deleteAll();
}

The business models have no idea where the messages are coming from and thats what the pattern wants to accomplish. Everything seems great.

Until you have a use case where you want to force a refresh with the server. Or only delete the messages from the local cache. Your interface would either need specific methods with names or params that imply the source type (both examples below). When a certain source type should be used is now defined by the objects on the wrong side of the repo interface. This feels like a violation to the pattern and defeating the whole purpose of using the interface in the first place.

interface MessagesRepo {
    List<Messages> getFromCloud();
    List<Messages> getFromCache();

    ... or ...

    void deleteAll(Source source);
}

Does it even make sense to try to use the repository pattern in this situation? Or does it make sense to accept that some storage details are important to my business logic and will need to be defined there?

Either way I would have an interface around the actual local/remote access classes so at least if I want to change from a db to a text file or something, I'm not tied up there.

But maybe those access interfaces make more sense to be used in the business model rather than this "repo" interface that feels like a violation?

Anyone else run into this problem and solve it a different way?