Conflict resolution last updateAt win

[hortigado]

Hello, I've been having a problem with conflict resolution lately. If a device has an old update queued, it overwrites the new one when it connects to the internet. I'd like to see if it's possible to develop a conflict system for these cases.
🧩 Conflict resolution strategies: client wins, server wins, timestamp, or custom
Could we have an updatedAt field in our models that, if a date older than that is already found on the server, doesn't update it?

abstract class ConflictResolver<T> {
  T resolve(T local, T remote);
}

class ClientWinsResolver<T> implements ConflictResolver<T> {
  @override
  T resolve(T local, T remote) => local;
}

class ServerWinsResolver<T> implements ConflictResolver<T> {
  @override
  T resolve(T local, T remote) => remote;
}

class TimestampResolver<T> implements ConflictResolver<T> {
  @override
  T resolve(T local, T remote) {
    // Assuming models have a updatedAt field
    // This is a generic implementation - specific models should override
    if (local is Map && remote is Map) {
      final localTimestamp = local['updatedAt'] ?? 0;
      final remoteTimestamp = remote['updatedAt'] ?? 0;
      return localTimestamp >= remoteTimestamp ? local : remote;
    }
    
    // For objects with timestamp property
    try {
      final localTimestamp = (local as dynamic).updatedAt ?? 0;
      final remoteTimestamp = (remote as dynamic).updatedAt ?? 0;
      return localTimestamp >= remoteTimestamp ? local : remote;
    } catch (e) {
      // Fallback to client wins if timestamp comparison fails
      return local;
    }
  }
} 

[tshedor]

@hortigado having a ConflictResolver is an interesting idea. I don't want to be overly prescriptive by adding an updatedAt to every Brick model because you would need an updatedAt field for each provider (i.e. updatedAtSqlite) you're using to do true deserialization and reconciliation. However, the implementation could do that and define their own ConflictResolvers.

in this architecture, where would the resolution take place? On hydrate? Earlier?

[hortigado]

Hi, thanks for the answer. I need it on upsert with method update. Yes, I think it should be before, and if you get an updated document, update it locally. This way, the local database would be updated at the same time. You could also return the updated document if you have awaitRemote.