mod_report_affiliations: Fix traceback a non-user is sending a presence For now we won’t touch their presence instead of emiting this traceback: error Traceback[s2s]: /usr/lib/prosody/core/rostermanager.lua:275: attempt to concatenate a nil value (local 'username') stack traceback: /usr/lib/prosody/core/rostermanager.lua:275: in function 'prosody.core.rostermanager.is_user_subscribed' ...ules/mod_report_affiliations/mod_report_affiliations.lua:116: in field '?' /usr/lib/prosody/util/events.lua:81: in function </usr/lib/prosody/util/events.lua:77> (...tail calls...) /usr/lib/prosody/core/stanza_router.lua:184: in upvalue 'core_post_stanza' /usr/lib/prosody/modules/mod_presence.lua:244: in function </usr/lib/prosody/modules/mod_presence.lua:231> (...tail calls...) /usr/lib/prosody/util/events.lua:81: in function </usr/lib/prosody/util/events.lua:77> (...tail calls...) /usr/lib/prosody/core/stanza_router.lua:188: in upvalue 'core_post_stanza' /usr/lib/prosody/core/stanza_router.lua:128: in upvalue 'core_process_stanza' /usr/lib/prosody/modules/mod_s2s.lua:818: in upvalue 'func' /usr/lib/prosody/util/async.lua:149: in function </usr/lib/prosody/util/async.lua:147>

---
summary: Multi-backend storage module (WIP)
labels:
- NeedDocs
- Stage-Alpha
...

Introduction
============

This module attemtps to provide a storage driver that is really multiple
storage drivers. This could be used for storage error tolerance or
caching of data in a faster storage driver.

Configuration
=============

An example:

``` {.lua}
storage = "multi"
storage_multi_policy = "all"
storage_multi = {
    "memory",
    "internal",
    "sql"
}
```

Here data would be first read from or written to [mod\_storage\_memory],
then internal storage, then SQL storage. For reads, the first successful
read will be used. For writes, it depends on the `storage_multi_policy`
option. If set to `"all"`, then all storage backends must report success
for the write to be considered successful. Other options are `"one"` and
`"majority"`.