Unable to Fetch Data from API Container Using Sockets in Perseus Container

[afidegnum]

This issue is reporting a bug in the code of Perseus. Details of the scope will be available in issue labels.
The author described their issue as follows:

Unable to Fetch Data from API Container Using Sockets in Perseus Container

I'm currently facing an issue where I'm unable to fetch data from the API container (api) from the Perseus container (front) using sockets.
I'm always greeted with this error:

 warning: `front` (bin "front") generated 13 warnings (run `cargo fix --bin "front"` to apply 7 suggestions)
487.6     Finished release [optimized] target(s) in 7m 21s
487.6      Running `dist/target_engine/release/front`
487.6 Error: render function 'build_state' in template '' failed (cause: Server(None))
487.6
487.6 Caused by:
487.6   Hyper error: error trying to connect: No such file or directory (os error 2)
------

Interestingly, this operation executes successfully when not running inside a container. Additionally, I was able to test the socket between containers using netcat and confirmed it to be working.

Interestingly, this operation executes successfully when not running inside a container. Additionally, I was able to test the socket between containers using netcat and confirmed it to be working.

In an attempt to isolate the problem, I created a separate crate for testing (hypertest). During these tests, I noticed that introducing timeouts seemed to alleviate the issue. However, I have not used Perseus in this context and I am unsure if this is an appropriate solution or merely a workaround.

Steps to Reproduce:

Here are the steps to reproduce the issue:

You can locate the REST client at https://github.com/afidegnum/SockerTest/blob/main/front/src/httpreq/mod.rs#L127

You can try request_client or client_request functions.

the build_state is located at: https://github.com/afidegnum/SockerTest/blob/main/front/src/templates/latest.rs#L159

Any insights or suggestions would be greatly appreciated. Thank you!

The steps to reproduce this issue are as follows:

Everything is inside the docker container, Clone the repo, launch the containers (docker-compose up) in order:

• age (the database )
• api (the api server)
• front (perseus )

A minimum reproducible example is available at https://github.com/afidegnum/SockerTest.

• Hydration-related: false
• The author is willing to attempt a fix: false

The same issue happens when I use use tokio::net::UnixStream;

#[cfg(engine)]
pub async fn request_client<T: DeserializeOwned>(
    path: String,
) -> Result<T, Box<dyn std::error::Error>> {
    use crate::SOCKET_ADDR;

    // Connect to the Unix socket
    let mut stream = UnixStream::connect(SOCKET_ADDR).await?;

    // Write the request to the socket
    let request = format!("GET {} HTTP/1.1\r\n\r\n", path);
    stream.write_all(request.as_bytes()).await?;

    // Read the response from the socket
    let mut response = String::new();
    stream.read_to_string(&mut response).await?;

    // Parse the JSON body of the response
    let start_of_body = response.find("\r\n\r\n").ok_or("Invalid HTTP response")? + 4;
    let body = &response[start_of_body..];
    let res: T = serde_json::from_str(body)?;

    Ok(res)
}

Tribble internal data

dHJpYmJsZS1yZXBvcnRlZCxDLWJ1ZyxBLWRlcGxveW1lbnQ=

[arctic-hen7]

As I said on Discord, I would try without cache_fallible_res to see if that's the problem. If not, I'll play around with this tomorrow.