test: remote requests are now replayed

[quintesse]

This way we don't rely on external services being up or being rate limtied.

[quintesse]

Converted to draft because there are still some things not quite right.

[quintesse]

It works, but now the build fails with an OOM exception during the unit tests :-/
I'd need to figure out if we can give the test runner some more memory in the GH action.

[maxandersen]

why does it need more memory??

[quintesse]

I'm guessing because it keeps the requests in memory? Not sure. It doesn't seem that much traffic.

[maxandersen]

fyi: i fixed the blusky issue - for some reason it kept giving my user invalid handle causing blusky url not to work.

still this pr has merits to explore - just wondered if the trigger was the random blusky errors :)

[quintesse]

still this pr has merits to explore - just wondered if the trigger was the random blusky errors :)

The current trigger was indeed this blusky issue :-)
But it had been bothering me for the longest time that the CI randomly fails because of connection errors, server problems, rate limits, etc

[quintesse]

I'm not really happy with how WireMock handles record/replay of requests, I'm going to try to see if switching to Hoverfly is a better option.

[quintesse]

In the end Hoverfly came with its own set of problems so went back to making WireMock work and it seems I was successful.

[quintesse]

@maxandersen we should really take a look at merging this, see how often the CI actions fail for example here: #1991 @wfouche had to ask me several times to restart the build.

[maxandersen]

sorry, missed the update. marking as approved and merge when test passes

[maxandersen]

@quintesse any idea of why this is failing with timeout in tests?

[quintesse]

@quintesse any idea of why this is failing with timeout in tests?

It's not timeouts , it's OOM again.

It didn't happen the last couple of times so I didn't make any changes in that respect, but I do have some ideas on how to fix it.

(Basically all requests and their results are kept in memory by WireMock once you initialize it. And because I initialize it at the start of the first test until the last test finishes we might be storing a lot of data in memory. I think I can fix this by simply limiting its "scope", for example to init for each test class, perhaps even for each test. I'll have to see if that slows things down or not)

[quintesse]

Marking as Draft for now until I have some time to look at it.

[quintesse]

Ok, so I again took a look at what was happening and it's basically because some tests cause relatively big downloads. The new Kotlin Export test causes a 80MB download! Which WireMock chokes on. Now while investigating what I could do about that I realized that I'm probably trying to do too much with WireMock, like trying to shove a block into a round hole. Given the fact that I;m only using it as a proxy that writes its requests to disk to be replayed at a later time, I'm seriously considering just writing that myself. It seems easy (famous last words).

Edit: btw, I'm going to fix those exports, they shouldn't be downloading anything.
Edit2: darnit, I remember why they build: it's to get the name of the main class. And for somebody doing the export I guess the download is not a problem, they are working with Groovy/Kotlin anyway. But for the tests it's a bit much. So I guess I'll disable them for now.