Summary
Bridge::switchBackend takes a std::unique_ptr, i.e. it consumes the backend:
void switchBackend(std::unique_ptr<::morph::backend::detail::IBackend> newBackend);
That cannot express re-installing a backend instance the caller still owns.
Use case
An application that toggles between a remote and a local backend as connectivity comes
and goes typically holds one long-lived remote backend for the lifetime of the
process — it owns the socket, the reconnect timer and the pending-request state — and
swaps the Bridge between that instance and a local one:
auto remote = std::make_shared<SomeRemoteBackend>(url);
auto local = std::make_shared<LocalBackend>(pool);
// Connection lost — fall back.
bridge.switchBackend(local);
// Reconnected — put the *same* remote instance back.
bridge.switchBackend(remote); // cannot be expressed with unique_ptr
With the current signature the caller has to either give up ownership on the first
switch (and then has nothing to switch back to), or construct a fresh remote backend on
every transition — which throws away the connection state that made it worth keeping.
Suggested fix
Add a shared_ptr overload and let the unique_ptr one delegate to it:
void switchBackend(std::shared_ptr<::morph::backend::detail::IBackend> newBackend);
void switchBackend(std::unique_ptr<::morph::backend::detail::IBackend> newBackend) {
switchBackend(std::shared_ptr<...>{std::move(newBackend)});
}
This is additive only — existing call sites are unaffected. The implementation already
converts to shared_ptr internally on its first line, so the overload mostly removes a
conversion the caller currently cannot perform.
Related: the rollback-on-partial-failure path inside switchBackend behaves the same
either way, since it operates on the converted pointer.
Happy to open a PR.
Summary
Bridge::switchBackendtakes astd::unique_ptr, i.e. it consumes the backend:That cannot express re-installing a backend instance the caller still owns.
Use case
An application that toggles between a remote and a local backend as connectivity comes
and goes typically holds one long-lived remote backend for the lifetime of the
process — it owns the socket, the reconnect timer and the pending-request state — and
swaps the Bridge between that instance and a local one:
With the current signature the caller has to either give up ownership on the first
switch (and then has nothing to switch back to), or construct a fresh remote backend on
every transition — which throws away the connection state that made it worth keeping.
Suggested fix
Add a
shared_ptroverload and let theunique_ptrone delegate to it:This is additive only — existing call sites are unaffected. The implementation already
converts to
shared_ptrinternally on its first line, so the overload mostly removes aconversion the caller currently cannot perform.
Related: the rollback-on-partial-failure path inside
switchBackendbehaves the sameeither way, since it operates on the converted pointer.
Happy to open a PR.