Skip to content

[BUG] Last Release (3.2.0) is broken. SenderOptions.addr is ignored, causing fallback to localhost:9000 and IngressError #63

@ogoun

Description

@ogoun

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 error

Expected 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions