GrpcUds failure management

[fabricedesre]

In default rpc config, iroh-one chooses a default gateway address at https://github.com/n0-computer/iroh/blob/7b2f9a76abb0c6de6d9a760389fc1d24191f8b38/iroh-one/src/config.rs#L68 which ends up being something like grpc:///tmp/iroh.0J0MJzroZ35R/ipfsd.http.

That doesn't work because the directory doesn't exist, so binding to the UDS fails at https://github.com/n0-computer/iroh/blob/7b2f9a76abb0c6de6d9a760389fc1d24191f8b38/iroh-rpc-types/src/macros.rs#L48

Unfortunately we swallow the error silently in https://github.com/n0-computer/iroh/blob/7b2f9a76abb0c6de6d9a760389fc1d24191f8b38/iroh-gateway/src/core.rs#L61

Apart from at least logging the error in core.rs when it happens, should we create the parent directory of the UDS socket when it doesn't exist? This patch makes things work, but I'm not sure if we want that behavior:

diff --git a/iroh-rpc-types/src/macros.rs b/iroh-rpc-types/src/macros.rs
index 4b15464..eae2fa4 100644
--- a/iroh-rpc-types/src/macros.rs
+++ b/iroh-rpc-types/src/macros.rs
@@ -37,6 +37,12 @@ macro_rules! proxy {
                                 anyhow::bail!("cannot bind socket: already exists: {}", path.display());
                             }
                         }
+
+                        // Create the parent directory if needed.
+                        if let Some(parent) = path.parent() {
+                            let _ = std::fs::create_dir_all(&parent);
+                        }
+
                         // Delete file on close
                         struct UdsGuard(std::path::PathBuf);
                         impl Drop for UdsGuard {

@dignifiedquire what do you think?

[dignifiedquire]

I explicitly didn’t go for this option as I have seen a lot of failure cases with uds paths and permissions. I would prefer just logging better errors on config validation so the operator can fix things

[dignifiedquire]

we should potentially create the directory explicitly in the tempdir case, as we know we are making it

[Arqu]

Should we close this?

[fabricedesre]

Yes, fixed in 8d13e4f