test(python): let a weblog declare its request timeout, 10s for uwsgi-poc - #7596
Conversation
|
|
🎉 All green!🧪 All tests passed 🔄 Datadog auto-retried 7 jobs - 7 passed on retry 🔗 Commit SHA: adb6d2f | Docs | View more details | Give us feedback! |
405f3a9 to
ef9b450
Compare
christophe-papazian
changed the title
ef9b450 to
c3ffad6
Compare
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c3ffad63a3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…-poc The uwsgi-poc weblog occasionally stalls for several seconds on a single early request, which exceeds the 5s read timeout in the weblog client. The request then has no response at all and the test fails on a null status code, even though the weblog answered correctly a moment later. Observed in CI: the whole worker process freezes for ~5s while the first subprocess is spawned, and the weblog returned 403 after 6517ms while the client had already given up at 5000ms. The trace itself was flushed normally and collected mid-run, so only the HTTP leg was affected. Make the client's default read timeout configurable, and let a weblog declare its own value in its library's weblog_metadata.yml rather than being special-cased in containers.py. Only uwsgi-poc declares one; every other weblog keeps the 5s default, and explicit per-call timeouts are unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
c3ffad6 to
ab4105e
Compare
nccatoni
left a comment
nccatoni
left a comment
There was a problem hiding this comment.
Did you try using https://github.com/DataDog/system-tests/actions/workflows/debug-harness.yml to confirm that this change resolves the flakiness? I’d like to ensure it addresses the issue reliably before increasing the timeout. Ideally, we should identify the root cause of the delay, since five seconds is already quite long.
@nccatoni The very low flakyness would have been avoided with this change for sure. I tried debug-harness.yml on https://github.com/DataDog/system-tests/actions/runs/32986639106 |
3 participants
APPSEC-69833
uwsgi-pococcasionally stalls a few seconds on an early request, exceeding the weblog client's 5s read timeout. The test then gets no response at all and fails on a null status code, though the weblog answered a moment later (seen in CI: 403 after 6517ms, client gave up at 5000ms). The trace was flushed and collected normally, so only the HTTP leg was affected.Makes the client's default read timeout configurable, declared per weblog in
weblog_metadata.yml. Onlyuwsgi-pocsets one (10s); every other weblog keeps 5s, and explicit per-call timeouts are unchanged.This reduces flake exposure, it does not explain the stall — still under investigation.