jetstream - setting allow_msg_ttl on a stream that had it on doesn't return an error

[aricart]

Observed behavior

Previously the server rejected requests to change allow_msg_ttl when it was true to false with the message subject marker delete cannot be set if message TTLs are disabled now it simply doesn't do the update, but doesn't return an error

Expected behavior

Return an error

Server and client version

2.11.2

Host environment

any

Steps to reproduce

const jsm = await jetstreamManager(nc);
  const si = await jsm.streams.add({
    name: "A",
    subjects: ["a"],
    allow_msg_ttl: true,
    subject_delete_marker_ttl: nanos(60_000),
  });
  assertEquals(si.config.allow_msg_ttl, true);
  assertEquals(si.config.subject_delete_marker_ttl, nanos(60_000));

  await assertRejects(
    () => {
      //@ts-expect-error: this is a test
      return jsm.streams.update("A", { allow_msg_ttl: false });
    },
    Error,
    "subject marker delete cannot be set if message TTLs are disabled",
  );

[MauriceVanVeen]

Since 4ca4b98 we now default AllowMsgTTL if SubjectDeleteMarkerTTL is set.

If pedantic is set on the update request then this error will be returned.

[ripienaar]

Of the 2 I think the Boolean should be authoritative - go Boolean handling isn’t helping sigh.

[aricart]

The pedantic option for JetStream - I implemented it for the javascript clients (it is opt-in), but current guidance is that clients won't implement it...

[MauriceVanVeen]

Then it's probably best to either remove that assertion, or adapt it to check AllowMsgTTL remains true because it's defaulted by SubjectDeleteMarkerTTL.