Fix failing go-dbhub CI test

[justinclift]

Ignore this for now.

The CI tests are failing, so this PR is just a way for me to trigger the CI tests while trying to figure out what's going on.

[justinclift]

Ugh. This is making absolutely no sense to me at all.

The local DBHub.io daemons are clearly running and available for the go-dbhub test, as doing a netstat -nltp shows them to be there:

tcp        0      0 0.0.0.0:9443            0.0.0.0:*               LISTEN      -
...                   
tcp6       0      0 :::9443                 :::*                    LISTEN      -

Seeding the database works fine when testing locally in my system, and also works fine in the Cypress CI testing run for this PR. So why the hell is it failing when it's run as part of the go-dbhub library test?

2024/03/08 12:07:04 Seeding the database...
2024/03/08 12:07:04 Get "https://localhost:9443/x/test/seed": read tcp [::1]:59528->[::1]:9443: read: connection reset by peer
exit status 1
FAIL	github.com/sqlitebrowser/go-dbhub	0.008s

[justinclift]

Ok, it looks like the problem also happens when trying to seed the database manually using curl:

$ curl -k https://localhost:9443/x/test/seed
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to localhost:9443 

This feels like some change in the GitHub infrastructure has happened, breaking stuff. Not sure what yet.

[justinclift]

So, whatever the problem is... it's not an IPv4 vs IPv6 thing as connecting to 0.0.0.0 instead of localhost (which forces IPv4) also didn't work.

[justinclift]

Ok, so it looks like TLS/SSL itself is completely broken somehow:

$ sh -c 'echo "Q" | openssl s_client -connect localhost:9443'
write:errno=104
CONNECTED(00000003)
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 283 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
Error: Process completed with exit code 1.

Hmmm. Maybe it'll work if we use http instead of https?

[justinclift]

Nope, that didn't work either:

$ curl http://0.0.0.0:9443/x/test/seed
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (56) Recv failure: Connection reset by peer

It's almost like the calls to port 9443 are being intercepted by some other non-DBHub.io process, fucking everything up.

[justinclift]

That's interesting. It looks like it started the docker DBHub.io daemons on the old port, even though this PR has updated it.

Sounds like it's not testing the source code in this PR (maybe using master instead?) when it's running the test.

[justinclift]

I've just created an Ubuntu 20.04 VM on my local development pc, and set that up as a GitHub Runner.

Going to debug this further using that local GitHub Runner, as I can log in directly to that VM and try to figure out what is going wrong.

[justinclift]

Aarrrrgh. This makes no sense.

When running the curl command to seed the database via the GitHub Action, it's failing on my local VM just the same as with the GitHub hosted runners:

$ curl -k https://localhost:9443/x/test/seed
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to localhost:9443 

But running the exact same command (cut-and-pasted!) from the exact same user manually... works completely fine.

WHAT THE HELL IS GOING ON?

[justinclift]

Holy crap. It actually passed this time around. Now to figure out why exactly... 😉

[justinclift]

k. It looks like the actual problem was the DBHub.io daemons needed more time to start in the Docker container.

At least that's an easy thing to fix... after spending hours trying to figure out what the problem was. 😄

[lucydodo]

Looks like the issue has been resolved, Thank you. :)

[justinclift]

Yeah, finally figured it out. 😄