Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
afidegnum opened this issue Jan 14, 2024 · 1 comment
Labels
A-deployment Area: deployment C-bug Category: bug tribble-reported This issue was reported through Tribble.

Comments

@afidegnum
Copy link
Contributor

afidegnum commented Jan 14, 2024

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=

@github-actions github-actions bot added A-deployment Area: deployment C-bug Category: bug tribble-reported This issue was reported through Tribble. labels Jan 14, 2024
@arctic-hen7
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-deployment Area: deployment C-bug Category: bug tribble-reported This issue was reported through Tribble.
Projects
None yet
Development

No branches or pull requests

2 participants