Skip to content

Test Updates to Align with Header Removal from APIcast Midstream#1029

Open
cathal-bailey wants to merge 2 commits into
3scale-qe:mainfrom
cathal-bailey:onfailed-openresty-headers-removed
Open

Test Updates to Align with Header Removal from APIcast Midstream#1029
cathal-bailey wants to merge 2 commits into
3scale-qe:mainfrom
cathal-bailey:onfailed-openresty-headers-removed

Conversation

@cathal-bailey
Copy link
Copy Markdown
Collaborator

@cathal-bailey cathal-bailey commented May 1, 2026

  • APIcast midstream update removes the Server header from HTTP responses. This breaks tests that rely on checking headers to confirm APIcast is responding.
  • Update to the backoff mechanism to look for valid response code rather than server header. Ensures backoff logic remains in place and working, in case it is needed.
  • test_do_not_send_openresty_version.py‎ also affected by midstream change.
  • Test now verifies that no server header or version information is disclosed anywhere.

@cathal-bailey cathal-bailey force-pushed the onfailed-openresty-headers-removed branch from 9a1e120 to 33fc4ad Compare May 1, 2026 13:27
@cathal-bailey cathal-bailey marked this pull request as ready for review May 1, 2026 13:28
mdujava
mdujava previously approved these changes May 4, 2026
…n.py to align with header removal in APIcast midstream
@cathal-bailey cathal-bailey changed the title Removing Headers From onfailed Policy Tests Test Updates to Align with Header Removal from APIcast Midstream May 8, 2026
@mdujava
Copy link
Copy Markdown
Member

mdujava commented May 11, 2026

are there any upstream changes or jira issue that shows this is expected change?

@cathal-bailey
Copy link
Copy Markdown
Collaborator Author

cathal-bailey commented May 11, 2026

are there any upstream changes or jira issue that shows this is expected change?

@mdujava
Copy link
Copy Markdown
Member

mdujava commented May 11, 2026

@backoff.on_predicate(
backoff.fibo,
lambda response: response.headers.get("server") not in ("openresty", "envoy"),
lambda response: response.status_code not in (200, 503, 500),
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.

There is bug. In the test where you are waiting for the 503, it can pass when it gets 200, then the test will fail on the wrong status code, but the only issue is that the test didn't wait enough time to load the configuration.

I also don't like that the range of the status codes is hardcoded. If there isn't other way how to detect that configuration is loaded, I would at least test the backoff against fixture status_code and set it to something, that doesn't collide with standard status codes (e.g 418) .

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

I could set a global variable expected_code returned from fixture status_code, then retry while response.status_code != expected_code? Then when retry passes, the response code will be the correct one

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.

I'm not sure how do you want set the global variable, but test response.status_code against expected_code seems like good approach to me. I would personally refactor make_request function, so it accepts status code as parameter, wrap return api_client.get("/") by a nested function and anotate that nested function by backoff with the correct condition.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants