-
Notifications
You must be signed in to change notification settings - Fork 11
Description
Description: I am encountering an issue where the SenderOptions.addr property seems to be ignored when initializing a Sender. Even though I provide a valid remote IP address in the options, the client attempts to connect to localhost:9000 (the default), resulting in a ServerFlushError.
I verified in the debugger that SenderOptions.addr is correctly set to my remote endpoint (192.168.0.218:9000) before calling Sender.New(), but the exception message explicitly states it cannot connect to localhost.
Steps to Reproduce:
Create a SenderOptions object specifying a remote address in addr.
Initialize the sender via Sender.New(options).
Attempt to send data (or wait for auto-flush).
Code Sample:
var endpoint = "192.168.0.218:9000"; // Valid remote QuestDB instance
var options = new SenderOptions
{
addr = endpoint,
init_buf_size = 104_857_600,
auto_flush = QuestDB.Enums.AutoFlushType.on,
auto_flush_interval = TimeSpan.FromSeconds(5),
max_buf_size = 838_860_800,
retry_timeout = TimeSpan.FromSeconds(5)
// username and password set if required
};
// The sender ignores 'endpoint' and tries to connect to localhost:9000
using var sender = Sender.New(options);
// Operations causing the flush triggers the errorExpected Behavior: The client should connect to the IP address specified in SenderOptions.addr (192.168.0.218:9000).
Actual Behavior: The client throws an exception indicating it tried to connect to localhost:
QuestDB.Utils.IngressError: 'ServerFlushError : Cannot connect to localhost:9000'
Environment:
QuestDB Client Version: 3.2.0
Target Framework: .NET 8.0
OS: Windows 10
Regression Confirmation: I have verified that this issue does not exist in version 3.1.1. When downgrading the library to 3.1.1, the exact same code and SenderOptions configuration work perfectly, and the client successfully connects to the remote address (192.168.0.218:9000). This suggests the problem was introduced in the recent update.