Refinements to MSG TTL spec during implementation

[ripienaar]

No description provided.

[ripienaar]

I think this is the only deviations so far? But please let me know about others and once you are done implementing we can merge this with all the changes included

[neilalexander]

Notes:

• Keep reject on Nats-TTL with TTLs disabled for client publishes, but allow keeping the header via sources/mirrors, just ignore them
• Ensure LimitsTTL cannot be enabled at the same time as mirroring
• Future option to remove individual headers on a per-source/mirror basis to remove TTLs later if we want

[ripienaar]

OK, so to summarise where we got to, would this be your understanding @neilalexander :

• We will accept Nats-TTL over sources/mirrors always and leave it as is
• If the Source has ttl handling enabled we will process it
• Mirrors may not enable that setting

right?

[neilalexander]

As it stands, AllowMsgTTL can be enabled on a mirror but LimitsTTL cannot be. Otherwise yep, that's right.

[ripienaar]

As it stands, AllowMsgTTL can be enabled on a mirror but LimitsTTL cannot be. Otherwise yep, that's right.

updated with bd022dc to capture these

[Jarema]

LGTM

[ripienaar]

Have updated with the split in delete markers and TTL with a default.

Note this has the side effect that already deployed streams will have their running behaviour changed without user input or control should the server later update this default.

[ripienaar]

Updated again for defaults being placed in the config unless pedantic

[neilalexander]

LGTM

[aricart]

This setting is really not needed - the TTL setting is going to be highly dependent on the use-case, so auto-setting it is not the right approach - user should just specify the SubjectDeleteMarkerTTL and that infers that SubjectDeleteMarkers

[neilalexander]

We had this conversation quite a few times, but the prevailing problem is that unless KVs etc are setting it for you, that users setting this on their own streams may have no way to intuitively know what a sensible value even is, i.e. for lost connections, ordered consumer recreation, etc, hence the "sensible default".

[ripienaar]

We also do not know what a correct setting is. If a user cannot pick a default, neither can we. All we are doing is guaranteeing that people will feel the system is broken rather than that it is behaving in a way that they chose - even if at the time of choosing they might not have realised the full weight of the choice.

We are still pretending we can answer the question: What is the default outage time?

We can not.

Further this pushes a bunch of complexity onto everywhere, want to unset this setting now there are other coupled settings to also unset and understand etc.

I am, still, strongly against this design.