Open schildbach opened 8 months ago
Does this actually happen for HTTP errors (status codes), or just timeouts/connection refused/DNS errors at the proxy etc?
I would expect the latter (and for 503 that makes sense). Agreed we should treat this just like a TCP-level error.
I think both.
For reference, timeouts are much less spammy when no outbound proxy is used:
2024-01-31 12:58:05,213 - synapse.util.retryutils - 283 - INFO - federation_transaction_transmission_loop-21405 - Connection to matrix.dagfinsen.no was unsuccessful (<class 'synapse.api.errors.RequestSendFailed'>(Failed to send request: TimeoutError: User timeout caused connection failure.)); backoff now 604800000
2024-01-31 12:58:05,214 - synapse.federation.sender.per_destination_queue - 417 - WARNING - federation_transaction_transmission_loop-21405 - TX [matrix.dagfinsen.no] Failed to send transaction: Failed to send request: TimeoutError: User timeout caused connection failure.
Or this is a cancelled connection:
2024-01-31 13:02:45,623 - synapse.util.retryutils - 283 - INFO - federation_transaction_transmission_loop-545 - Connection to mtx.0ef.de was unsuccessful (<class 'synapse.api.errors.RequestSendFailed'>(Failed to send request: ResponseNeverReceived: [<twisted.python.failure.Failure twisted.internet.defer.CancelledError: >])); backoff now 600000
2024-01-31 13:02:45,623 - synapse.federation.sender.per_destination_queue - 417 - WARNING - federation_transaction_transmission_loop-545 - TX [mtx.0ef.de] Failed to send transaction: Failed to send request: ResponseNeverReceived: [<twisted.python.failure.Failure twisted.internet.defer.CancelledError: >]
Failed certificate verification:
2024-01-31 13:04:04,724 - synapse.util.retryutils - 283 - INFO - federation_transaction_transmission_loop-26242 - Connection to imyxh.net was un
successful (<class 'synapse.api.errors.RequestSendFailed'>(Failed to send request: RequestTransmissionFailed: [<twisted.python.failure.Failure OpenSSL.SSL.Error: [('system library', '', ''),
('system library', '', ''), ('SSL routines', '', 'certificate verify failed')]>])); backoff now 1187939
2024-01-31 13:04:04,724 - synapse.federation.sender.per_destination_queue - 417 - WARNING - federation_transaction_transmission_loop-26242 - TX
[imyxh.net] Failed to send transaction: Failed to send request: RequestTransmissionFailed: [<twisted.python.failure.Failure OpenSSL.SSL.Error: [('system library', '', ''), ('system library',
'', ''), ('SSL routines', '', 'certificate verify failed')]>]
Description
I started proxying outbound requests via HTTP proxy (Squid), and now every remote server problem (HTTP error from peer, even transient HTTP errors, DNS error) is being logged with error level CRITICAL and includes a lengthy stack trace that doesn't help because the problem is caused by a federating peer.
See example log output below.
I would argue that remote servers errors should be logged at a much lower level, maybe INFO. And it should not contain any stack trace, as that's useless.
My proxy specific config (for docker-compose):
Steps to reproduce
Homeserver
matrix.schildbach.de
Synapse Version
1.99.0
Installation Method
Docker (matrixdotorg/synapse)
Database
postgres, single
Workers
Single process
Platform
Docker version 20.10.24+dfsg1, build 297e128
Configuration
No response
Relevant log output
Anything else that would be useful to know?
No response