Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions nix/tests/default.nix
Original file line number Diff line number Diff line change
Expand Up @@ -642,6 +642,12 @@ in
"curl --fail --max-time 5 https://hello.corp.example.com/"
)

# Wait until the proxy has fully established its internal tunnel.
node.wait_until_succeeds(

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I don't understand how this is fixing anything here. The next line is going to be doing the very much same thing. Can you explain what are you trying to do?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does not do the same thing. wait_until_succeeds is used as a readiness barrier, not as the final assertion. portail.service being active and listening on port 8080 does not guarantee that the identity-aware upstream path is already usable.

We sometimes observe curl timeouts (exit code 28) in CI when the first proxied request happened too early (e.g. on latest commit, link), including in my PR CI.

This is currently a workaround to avoid the race condition. A better solution would be to have an explicit readiness signal from portail once the identity-aware upstream path is fully ready.

"curl --fail --silent --output /dev/null --max-time 5 --proxy http://127.0.0.1:8080 https://hello.corp.example.com",
timeout=30
)

# Test HTTP CONNECT curl -> portail -(TLS)-> portail (hop) -> corp-server
result = json.loads(node.succeed(
"curl --fail --max-time 5 --proxy http://127.0.0.1:8080 https://hello.corp.example.com"
Expand Down