http: making the lua filter a dual filter

[yuval-k]

Commit Message:
http: making the lua filter a dual filter
Additional Description: n/a
Risk Level: Low
Testing: Updated integration tests
Docs Changes: n/a
Release Notes: inline
Platform Specific Features: n/a
Part of #10455

[wbpcode]

/wait on ci

[yuval-k]

I'm seeing TSAN timing out in the middle of running the integration tests (the new integration test covers more combinations so it takes longer). I'm seeing the timeout set to 180 min in .github/workflows/_check_san.yml; but the test times out after 35 minutes.. do we know where the 35 min comes from?

2025-02-17T14:38:27.7895112Z -- Test timed out at 2025-02-17 14:34:47 UTC --

(I ran TSAN locally and it passes, so pretty sure it's just a time-out issue)

[wbpcode]

/retest

[wbpcode]

/retest

[yuval-k]

timeout still seems to be 30 min, even though I changed the test's size to enormous.
Locally this test takes around 1180 seconds, so I imagine it can cross the 1800 seconds in a slower CI VM.

I'm really not sure where that 30 minute value is coming from.. @wbpcode do you have any idea?

[wbpcode]

timeout still seems to be 30 min, even though I changed the test's size to enormous. Locally this test takes around 1180 seconds, so I imagine it can cross the 1800 seconds in a slower CI VM.

I'm really not sure where that 30 minute value is coming from.. @wbpcode do you have any idea?

Sorry, I also have no much idea. 😞 An eternal should use 3600s as the timeout. I think @phlax may could helps to this CI timeout problem.

[phlax]

this is the execution log https://mordenite.cluster.engflow.com/actions/executions/ChCgHfMQ0UNCiqLjEC0JFA-PEgdkZWZhdWx0GiUKIBR15GaFEZlQjH9EFo_3Ehks2raEKWcQQPwE5Z0MFeBPEKgD which suggests that the timeout is set to 4800s - so confused

either way - it would be better to avoid setting enormous

im wondering if the test can be made quicker - as 30m+ is a long time for a test

would increasing core count help at all?

[yuval-k]

would increasing core count help at all?

I believe google-test runs all the test of a single binary serially; so not sure if that would help. That said, if its easy to change, maybe worth a try?

[phlax]

yeah - given it fails reliably - change in the test rule rbe_pool = "6gig" -> rbe_pool = "2core"

[yuval-k]

Another option to make the test take less time is to remove http3 testing... not sure if it adds value for lua integration testing. running it locally without http3 takes around 600s which is ~50% percent less than before (1180s)