http'server 'listen on unix_sock should throw a error IF the-input-sockname-length EXCEED the maximum linux-limit

[navegador5]

What is the problem this feature will solve?

see the simple code below:

//suppose a-very-long-absolute-path  is used

var WORKDIR = "/mnt/sdb/NV5/NV5_/nvcli-/pkgs/PERF/nv-cli-how-many-workers/WORKDIR/DT20230603_093430_074_4211____nv_cli_how_many_workers___/"
fs.mkdirSync(WORKDIR);

/*
> console.log(child_process.execSync("pwd").toString())
/mnt/sdb/NV5/NV5_/nvcli-/pkgs/PERF/nv-cli-how-many-workers/WORKDIR


> console.log(child_process.execSync("tree -af").toString())
.
└── ./DT20230603_093430_074_4211____nv_cli_how_many_workers___

1 directory, 0 files
*/

//now listen on a unix-sock which created in this long dir:
var creat_srv = (idx=0)=> {
     let usock = `___usock${idx}___`;
     usock     = path.join(WORKDIR,usock);   
     try { fs.unlinkSync(usock);} catch(err) {}
     console.log("will listen on: ", usock)
    const server = http.createServer((req, res) => {
           res.writeHead(200, { 'Content-Type': 'text/plain' });
           res.end('okay');
    });
    server.listen(usock);
    return(server);
}

var s0 = creat_srv(0)

// the server s0 will success: 
/*
> s0._pipeName
'/mnt/sdb/NV5/NV5_/nvcli-/pkgs/PERF/nv-cli-how-many-workers/WORKDIR/DT20230603_094727_967_1235____nv_cli_how_many_workers___/___usock0___'
*/

//but:

console.log(child_process.execSync("tree -af").toString())

/*
.
├── ./DT20230603_093430_074_4211____nv_cli_how                                      //#0======> 【wrong name sock-file created】
└── ./DT20230603_093430_074_4211____nv_cli_how_many_workers___

1 directory, 1 file
*/

// check the trimmed length of  #0

/*
> "/mnt/sdb/NV5/NV5_/nvcli-/pkgs/PERF/nv-cli-how-many-workers/WORKDIR/DT20230603_093430_074_4211____nv_cli_how".length
107        -----------> 【107 is unix-sock  max-szie on my linux】
*/

so in this secenario .
i think server.listen should 【THROW-a-error】 instead of 【let-the-creat-action-succeed】

What is the feature you are proposing to solve the problem?

http'server 'listen on unix_sock should throw-a-error IF the-input-sockname EXCEED the maximum linux-limit

What alternatives have you considered?

in testbed enviroment:
long path name is NOT rare (coz the normally generated by script)
when auto creat many many server listen on unix sock in a nested directory, long path name is possible
for example, in my test bed , i created 2400 http server on a machine( for test one route one instance)
dt : 2400 created CPU:176 MEM: 1380974592
usock DT20230603_104937_506_5224____nv_cli_how_many_workers___/usock2400
some server name is too long, but they be created successfully with the wrong-sock-name(trimed)

[bnoordhuis]

Libuv issue, continues in libuv/libuv#4036. I already made that change in a pull request that's close to getting merged, although that was somewhat by accident.

[bnoordhuis]

FWIW, this particular quirk is documented in the libuv documentation. As such, libuv can't really change it without breaking backwards compatibility. The upcoming uv_pipe_bind2() and uv_pipe_connect2() functions could add a flag that makes them return an error instead of truncating the path.

[bnoordhuis]

When libuv/libuv#4040 lands and node upgrades to libuv v1.46.0, node can decide to use the new flag. Reopen the issue (or better, a pull request) if you think it's a good idea to change the current behavior.