Ah. Whereas I, as an email nonforum person expected that indicator on every reply because I’m not thinking about this as an instant messaging layout (maybe). So my expectations are at variance with what you’ve chosen to do.
It isn’t required. Think of it as “quality of service”. You explicitly go:
and you could just drop the [0] there. Clients could then use just one message-id or do something very funky at their whim and it would all be valid.
“Should” is a strong word. You could include all the message-ids if they’re easily to hand. You’re not obliged, and the code is valid as is.
Aye. I know I like it myself so that I know my post made it to the list/forum - email being very queue based and some (cough, large Australian telco, cough) ISP mail handlers being very… unreliable, slow, etc etc. Occasionally I have seen other people want this (in lists, but that’s the mode we’re effectively talking about here). The default for such an option should probably be false.
As a nerd, I like being at least able to get an unfiltered feed so that I can make my own policy decisions.
Given that the Message-ID is effectively opaque/set-once I don’t view that as a problem unless there’s scope for reissuing the same message-id - if all your counters are strictly monotonic I would not expect that to happen. I just found it very tedious to match up post.id eg 98 to topic/post eg 59/1. It would have been handy to have something like category.id/topic.id/post-in-topic.id there instead of the 98.
That would also be sufficient. This is just convenience on the debugging headers side.
That is still the old code you are looking at there, you only need to look at add_experimental_identification_field_headers . But your point still stands.
There is someone on our infrastructure team who would be agreeing firmly with this statement, they share a similar workflow and outlook to you
That’s fair enough, perhaps I will re-introduce topic ID as well, since outbound_message_id is indeed set once and not changed (based on whether the post is generated in the Discourse web UI or via an incoming email).
Probably won’t need this now since I am adding the topic ID into the Message-ID once more.
I’m actually not sure about this, I’ve got a gut feeling we don’t really want the topic ID in those Message-IDs, just having the post ID makes it super simple. Will try this instead:
That’s fine by me. I just found it particularly hard to tie email messages headers to posts because the post.id isn’t evident in the UI or the URL for the particular post on the web. Having that present in an additional context header would be just as good.
Hi Cameron, I’ve been at our company meetup then on vacation for the last 2 weeks, just getting back into the swing of things today. If it’s not merged this week then it will definitely be merged next week. Apologies for the delays!
By Martin Brennan via Discourse Meta at 20Sep2022 00:17:
Hi Cameron, I’ve been at our company meetup then on vacation for the
last 2 weeks, just getting back into the swing of things today. If it’s
not merged this week then it will definitely be merged next week.
Apologies for the delays!
No need for apologies. I knew you’d been away, wasn’t sure about your
timing or return. And I guess it might still be Monday where you are
I thought I’ve seen the odd glitch (two distinct threads on the one
topic, but I cannot see any examples at present), but I haven’t
characterised any of them yet, or eliminated my local mail folder as
being involved So I’ve no problems to report yet.
Thanks Cameron, great to hear! I’ll schedule this topic to close after another month, if it is closed and another issue comes up feel free to open another one