Desktop RTDB: Repo::HandleTransactionResponse collapses every non-datastale server error (incl. permission_denied) to kErrorUnknownError with an empty message

Inizia da database/src/desktop/core/repo.cc, in Repo::HandleTransactionResponse() e RerunTransactionQueue(), quindi confronta il flusso dello stato e del messaggio della risposta in database/src/desktop/connection/persistent_connection.cc. Il lavoro è completato quando gli errori delle transazioni conservano il codice di errore del server mappato e il messaggio, incluso permission_denied, invece di completarsi come kErrorUnknownError con un messaggio vuoto.

Environment

• Firebase C++ SDK 13.9.0 (desktop/Windows; the cited code is unchanged at the 13.11.0 tag)
• Identified while tracing FlutterFire firebase_database 12.4.6 on Windows; the defect below is independently confirmed from the pinned desktop C++ source.

What happens

When the server rejects a transaction commit (e.g. a security-rules fence returns permission_denied on the wire), the transaction Future<DataSnapshot> completes with:

• error() = kErrorUnknownError (10) — not kErrorPermissionDenied (8)
• error_message() = "" (empty)

so callers cannot distinguish "rules denied this commit" from any other failure, and there is no message to log. Plain SetValue() writes on the same path correctly surface kErrorPermissionDenied, which makes the transaction behavior surprising.

Where the information is lost (pinned to 3d7ce2a, the 13.9.0 tag)

1. The wire layer maps the response status correctly and retains the server message. HandlePutResponse() converts the status and passes the response body to TriggerResponse():
   https://github.com/firebase/firebase-cpp-sdk/blob/3d7ce2a584d0b8daf1374bc2534c6ea71fa7fd6c/database/src/desktop/connection/persistent_connection.cc#L955-L970
   TriggerResponse() stores both values, and the adjacent status map includes permission_denied → kErrorPermissionDenied:
   https://github.com/firebase/firebase-cpp-sdk/blob/3d7ce2a584d0b8daf1374bc2534c6ea71fa7fd6c/database/src/desktop/connection/persistent_connection.cc#L1244-L1281
2. Repo::HandleTransactionResponse() then discards both fields for every error response other than datastale:

   for (auto& transaction : response->queue()) {
     transaction->status = TransactionData::kStatusNeedsAbort;
     transaction->abort_reason = kErrorUnknownError;
   }
   

   https://github.com/firebase/firebase-cpp-sdk/blob/3d7ce2a584d0b8daf1374bc2534c6ea71fa7fd6c/database/src/desktop/core/repo.cc#L982-L1000
3. RerunTransactionQueue() finally completes the future with the no-message overload, so error_message() is empty:

   DataSnapshot snapshot(new DataSnapshotInternal(
       database_, node, QuerySpec(transaction->path)));
   transaction->ref_future->CompleteWithResult(transaction->future_handle,
                                               abort_reason, snapshot);
   

   https://github.com/firebase/firebase-cpp-sdk/blob/3d7ce2a584d0b8daf1374bc2534c6ea71fa7fd6c/database/src/desktop/core/repo.cc#L1003-L1138

Expected

abort_reason should carry the mapped response code (8 for permission_denied, etc.) and the completion should pass the response's error message through, matching what the Android SDK reports for the same server rejection.

Impact

Any desktop app implementing fenced/optimistic transactions (rules-enforced epochs, leases, counters) receives an undiagnosable unknown/empty failure for what is actually a well-defined rules denial. Downstream SDK wrappers (e.g. FlutterFire's Windows plugin) inherit the collapsed code, so the loss is user-visible in every binding built on this implementation.