How do other servers behave is there's some database error when adding archiving a message? (context: MAM)
flow
Zash: should be configurable and default to retry-panic
flow
question is, what the 'ignore' behavior should be? send once message (per day?) to the user stating that his messages are not archived?✎
Ge0rG
send a message error?
flow
question is, what the 'ignore' behavior should be? send one message (per day?) to the user stating that his messages are not archived? ✏
Ge0rG
panic = kill the server?
pulkomandyhas joined
Zash
I didn't ask what they should do. I asked what they *do*.
flow
good question if the message type should be error, but probably the answer is yes
flow
as long as there is a <body/>, and not just some error code that is often not shown to the user
flow
Zash, I know. But I expect some (most?) devs don't know, as error code paths are often not well tested
flow
or even not well known to the devs
flow
hmm another nice settings to have would probably be retry-notify-admin-ignore
Zash
I know what Prosody does as I've written a bunch of that code. No idea what ejabberd or Openfire or others do.
flow
Holger, any idea about ejabberd?
flow
Guus, any idea about openfire?
asterixhas left
jdevhas joined
Guus
Unsure. Probably silently ignore after writing the error to the logfile
asterixhas joined
Holger
So it's about a DB error on writing the MAM message? Then it's the same for ejabberd.
Zash
And Prosody too, ignore and carry on trying to deliver the message.
Zash
and write something to the error log
flow
Holger, DB error is the DB returning an error and/or the DB connection lost?
Holger
Both (if re-establishing the connection fails).
pulkomandyhas left
lovetox
i find it weird that you want to inform a user if something database wise happens on the server
lovetox
why not send a message to the admin?
lovetox
User cant do anything about it, but informing the administrator
flow
well the users UX is degraded, doesn't strike me as the badest idea to inform him✎
flow
well the user's experience is degraded, doesn't strike me as the badest idea to inform him ✏
flow
so that at least he knows that there is a reason his other clients do not show the same messages as he is used too
lovetox
A Adminstrator can also inform the users?
flow
note that I am talking about MAM archival not working, for whatever reason
lovetox
is this not his job if the service is degraded?
flow
lovetox, sure, that is why is also considered retry-notify-admin-ignore as setting
Holger
I would not send messages to users they can do nothing about other than notifying the admin.
flow
often database errors are simply returned to the requesting entity. for example, think if pubsub publish: if the item could not be persistet, then a service would probably return an IQ error
Holger
I think the options are "just notify the admin" vs. "bounce the message with an error".
flow
Holger, bounce the message to whom?
pulkomandyhas joined
Holger
The sender.
flow
but the message stil gets delivered?
flow
why should the sender care that the recipients MAM archive does not work?
Zash
I think this all depends on whether you want to have a store-and-forward system or not.
jonas’
bouncing an error to the sender if the message got delivered is going to be confusing
Holger
flow, well the question is whether MAM is considered critical or not.
jonas’
although, an excellent use-case of @type='continue'
Zash
I've assumed that delivery is the priority.
jonas’
but still, the sender can use that info even less
pep.
also careful with notifying the admin on a busy server. don't do that for every message :p
flow
Zash, the alternative to store-and-forward is potentially-store-and-forward?
flow
If so, I lean towards potentially-store-and-forward
lovetox
for all server errors, inform admin, admin can decide if he informs his users
jonas’
elitistly, I may say: logging as error should be enough. You should have monitoring which picks up on that.
Holger
jonas’, if a message is not delivered the sender does need an error message to be aware of the issue.
jonas’
but all those log monitoring stacks are insane
jonas’
Holger, 100% agree
jonas’
I’m reading backlog and replying ;)
flow
jonas’, true, but it's kinda right there to have your xmpp server notify the admin about issues ;)
Zash
Users (other devices) do get a hint that messages aren't stored, at least Prosody only adds the stanza-id if it successfully archived the message, which shows up in carbons.
jonas’
flow, sure
jonas’
mod_error_to_message which hooks into logging and rate-limitedly forwards error log messages to the admin?
"error: %s (and %d more instances)" | format("foo %s bar %d baz" | format(original_logging_arguments...), number_of_logentries_in_ratelimit_bucket)
flow
I see why service with thousands of users do not like the users to be automatically notified about a MAM outage, but I could imagine I would run my personal family service with such a setting enabled✎
kikuchiyohas left
flow
I see why a service with thousands of users may not be keen on users to be automatically notified about a MAM outage, but I could imagine I would run my personal family service with such a setting enabled ✏
kikuchiyohas joined
kikuchiyohas left
jonas’
do servers still assign a stanza-id on inbound messages if archiving fails?
jonas’
if not, a client could detect that passively and display an inline warning about that
flow
i'd assume that you can not assign an archive ID if your archive is unavaible
jonas’
it’s perfectly possible
flow
well unless you do the ejabberd thingy
jonas’
if you uuidgen all your IDs, you can do that before storing and only later realize that you did it
jonas’
I think '313 should specifically forbid that; it’ll cause pain once the archive service is restored
flow
it is still kind of odd that you assign an archive ID without being sure that this message will ever hit the archive
Holger
flow: But you're just adding a `<stanza-id/>` which you may well want to do independently of MAM, no?
Holger
flow: Didn't the XEP-0359 author consciously make this an independent XEP?
jonas’
uff, but then you’re in fun trouble
jonas’
because a client may have to do a full archive download because MAM will tell it that it doesn’t know that ID
Zash
maybe set the hostname as issuer of the id instead of the account?
Holger
ejabberd doesn't add a `<stanza-id/>` if the message wasn't archived, but I would've thought doing so would be perfectly fine. And I considered doing so in the past as some client dev(s) had some non-MAM related use case.
flow
Holger, true, but in this case the 'by' attribute of <stanza-id/> is typically known to be an address of an archive too
jonas’
cc @ MattJ
flow
but yes, there is nothing in xep359 which would prevent you from adding a stanza-id even if the archive is currentlyd own
flow
and I would not want it any other way
Holger
If that's not fine I don't see why 0359 would be a separate XEP at all. Given that 0313 hard-depends on it.
jonas’
Holger, there are other use-cases for stanza-id besides MAM, aren’t there?
Holger
So if clients need to know whether a message was archived we need a separate flag besides the <stanza-id/>.
flow
yeah, there is also the possibility that an alternative to MAM emerges that could also re-use xep359
flow
Holger, or, maybe better, a flat that the message was not archived✎
flow
Holger, or, maybe better, a flag that the message was not archived ✏
Holger
Or both.
flow
is there an advantage in having both? seems unnecessary to me, compared to simply flag the unexpected/unusual case
jonas’
flow, both allows a client to passively detect the support for setting the flags on the server
flow
i mean, we could have a stream feature that this "i-will-archive-messages-unless-flaged"✎
jonas’
no flag present -> no support; one flag present -> support && clear statement; both flags present -> ????
Holger
The client can't deduce a message was archived from the absence of a wasn't-archived flag, no? Except we add another feature.
Holger
That.
flow
i mean, we could have a stream feature that says "i-will-archive-messages-unless-flaged" ✏
Holger
Yes that would work as well.
Martinhas left
Martinhas joined
pulkomandyhas left
pulkomandyhas joined
pulkomandyhas left
MattJ
History: XEP-0313 originally had <archived id='...'/> and that certainly conveyed meaning that we have lost with the current protocol
MattJ
I have considered bringing it back (we really have to make the decision now)
kikuchiyohas joined
kikuchiyohas left
pulkomandyhas joined
Kev
I can't commit any brainpower to this today, but if the question is "do clients need to be told that a stanza was archived, and by whom", I think the answer is 'yes'.
Zash
What about the inverse?
MattJ
What's the inverse?
Zash
Do clients need to be told about failure to archive?
Zash
Kev, what does M-Link do if archiving fails?
MattJ
Part of the reason I was hesitant, is because with the IM-NG approach, I'm not sure there is much need for the additional signalling
jonas’
MattJ, signalling is useful in case of errors
jonas’
like the other day on yaxim
asterixhas left
asterixhas joined
MattJ
It's questionable what should happen in that case
jonas’
if a client knows that a stanza was, contrary to expectations, not archived, then you can avoid querying that stanza-id on next connect, leading to fun issues
MattJ
Should the stanza even be delivered? :)
Ge0rG
Great, let's re-add `<archived id='...'/>` into MAM and kill 0359.
jonas’
that’s a good question and should probably be configurable, but orthogonal, I think.
MattJ
Pre-MAM, failure to store an offline message would generate an error bounce
jonas’
if you ask me, the server should assign IDs and queue messages for archival and try it’s best to do it later
MattJ
MAM is basically per-device offline, and what we're saying is that partial delivery (i.e. only to currently online devices) counts as delivery, so it's ok
Ge0rG
what if the message was delivered to one of three clients, stored in offline store, but not MAM-archived?
jonas’
while havnig the message delivered with a flag indicating that it may not have been archived
jonas’
but that’s expensive to do, resource wise
jdevhas left
Ge0rG
jonas’: your suggestion would lead to an OOM crash with all the messages getting lost eventually
asterixhas left
kikuchiyohas joined
kikuchiyohas left
asterixhas joined
Zash
What if you can't archive the archiving failure notification?!!??!!!!?‽!!?
asterixhas left
asterixhas joined
Ge0rG
Zash: what if you generate an archiving failure notification for each archiving failure notification?