Noticed interesting sender behavior in JetStream

[Ivandemidov00]

There is currently no subject verification in the JetStream api.

If you use one connection to send several JetStream messages conditionally simultaneously and one of them has an invalid subject, then messages with a valid subject will also receive the error No response received from the server

The following questions appear:

• How generally acceptable is it to use a single connection for parallel shipments, from the library point of view nats.net ?
• Is it possible to add a subject validation to the jetStream api to identify an invalid subject before sending a request to the nats server?

    [Fact]
    public async Task Publish_invalid_subject()
    {
        await using var server = await NatsServer.StartJSAsync();
        await using var nats = await server.CreateClientConnectionAsync();
        var js = new NatsJSContext(nats);

        var stream = await js.CreateStreamAsync(
            config: new StreamConfig( "events", new[] { "events.*" }));
        var pub = async (string subject) =>
        {
            try
            {
                await js.PublishAsync(subject, new TestData { Test = 1 }, serializer: TestDataJsonSerializer<TestData>.Default);
                return Task.CompletedTask;
            }
            catch (Exception e)
            {
                _output.WriteLine(subject + " " + e.Message);
                return Task.CompletedTask;
            }
        };

        await Task.WhenAll(pub("events.before"), pub("events.invalid subject 1"), pub("events.afterFirstInvalid1"), pub("events.afterFirstInvalid2"), pub("events.invalid subject 2"), pub("events.afterSecondInvalid1"));
    }

Ouput:

events.invalid subject 1 No response received from the server
events.afterFirstInvalid2 No response received from the server
events.invalid subject 2 No response received from the server
events.afterFirstInvalid1 No response received from the server

P.S.
The behavior is not stable
When using PublishConcurrentAsync the behavior is similar

[mtmk]

the subject with space is causing protocol error and disconnecting the client.

[28412] 2025/02/20 10:52:56.326562 [ERR] 127.0.0.1:15644 - cid:12 - processPub Parse Error: "events.invalid subject 1 _INBOX.PB6L8rXtftpdQaDzukBwUX.VqMcCAQmP5AQyvzOER8jFP 1"
[28412] 2025/02/20 10:52:56.328632 [DBG] 127.0.0.1:15644 - cid:12 - Client connection closed: Protocol Violation

because they're all running concurrently by luck if one publishes right after disconnect, it is timing out and giving the same error some of the time.

NATS .NET is designed to work with concurrent operations but the application code needs to handle the errors.

in case of the subject with space as an invalid subject currently we don't have a protection against which might make it harder / impossible for applications handle the error. Let me check some of the other clients and with the team see how that's handled in general (remember this coming up before, i shall try to dig it out)

[mtmk]

OK, so the short answer is you need to do your own validation if your subjects can be generated from other inputs which might be any string. some guidelines are here https://docs.nats.io/nats-concepts/subjects#characters-allowed-and-recommended-for-subject-names but

AFAIU, the main reason for the NATS client not to do the subject validation is not to create any performance loss and leave the validation to the server to avoid issues among different clients. So it is left to applications to build their subjects correctly and test before using their way of building subjects.