Fix flaky tests. Reproducer:
go test -run TestHashMailServerReturnStream -count=20
TestHashMailServerReturnStream fails because the test cancels a read stream
and immediately dials RecvStream again expecting the same stream to be handed
out once the server returns it. The hashmail server implemented
RequestReadStream/RequestWriteStream with a non-blocking channel poll and
returned "read/write stream occupied" as soon as the mailbox was busy. That
raced with the deferred ReturnStream call and the reconnect often happened
before the stream got pushed back, so clients received the occupancy error
instead of the context cancellation they triggered.
Teach RequestReadStream/RequestWriteStream to wait for the stream to become
available (or the caller's context / server shutdown) with a bounded timeout.
If the wait expires we still return the "... stream occupied" error, so callers
that legitimately pile up can see that signal. The new streamAcquireTimeout
constant documents the policy, and the blocking select removes the race, so
reconnect attempts now either succeed or surface the original context error.
Register the Aperture instance created in setupAperture with t.Cleanup so
that every test stops its own server even if it fails. This keeps the global
HashMail stream map clean and prevents TestHashMailServerLargeMessage from
inheriting leftover streams from TestHashMailServerReturnStream.
This prevents cascading test failures, when a failure in one test is replicated
as many failures in many tests, complicating debugging from logs.
Go 1.25 tightened x509 validation and now rejects empty dNSName entries, causing
the default self-signed cert generation to fail when ServerName is left unset
(`x509: SAN dNSName is malformed`). Filter out empty host names before calling
cert.GenCertPair and reuse the same SAN list when renewing, allowing the default
config to keep working. Add a unit test that reproduces the failure.
In this commit, we add a new CLI argument that allows a user to control
if we use strict verification or not. Strict verification relies on
checking the actual invoice state against lnd, and requires more state
for the Aperture server.
When strict verification isn't on, we rely only on the preimage payment
hash relationship. Namely that the only way a user can obtain the
preimage is to pay the invoice, and as we check the HMAC on the
macaroon, we know that we created it with an invoice obtained from lnd.
Prior we would not set the Content-Type header for
grpc request, which on failure events would cause
the response to be invalid gRPC responses, as the
grpc code path in sendDirectResponse expects the
Content-Type header to be set.
This change fixes the problem by setting the
Content-Type header to application/grpc for gRPC
requests.
If a TokenID is passed by value to logging functions (such as the Printf family)
the pointer-based String() method is not used. As a result, the token is logged
as an array when using %v and as binary when using %s, which is inconvenient.
