Tags: ServiceFoundation/kazoo
Tags
[4.3] KCRO-15: expose transcription capabilities in the crossbar auth… …entication response (2600hz#6342) * [4.3] KCRO-15: expose transcription capabilities in the crossbar authentication response * KCRO-15: change supported to available for consistency * KCRO-15: expose known APIs as well * KCRO-15: make apis
[4.3] KCRO-10: expose the message counts per folder when listing vmbo… …xes (2600hz#6315) When listing the voicemail boxes this adds a new object to each called "folders" if the vmbox has messages. The object contains two properties that represent the quantity of messages in the 'new' and 'saved' folders.
handle terminate/2 errors when federator process has exited (2600hz#6302 )
[4.3] Listener federators and memory improvements (2600hz#6297) * [4.3] Listener federators and memory improvements Prior, when a gen_listener needed to federate its queue and bindings to other zones, it would start_link the listener_federator (and trap exits). However, should a listener_federator process actually exit, the parent gen_listener would receive the EXIT message but failed to have a handle_info clause to restart the process. Introduce a sofo supervisor for starting listener_federator processes and restart them if they die unexpectedly (non-normal exits). Secondly, introduce memory consumption checks and GC gen_listeners when they exceed 100K in total_heap_size. In addition, copy the binary payloads as they arrive off the AMQP channel has shown to decelerate the memory growth as the original binary can be garbage collected sooner and not count against the gen_listener's "old" heap. All told, these manual GC runs appear to be minimal and only affect long-running and busy gen_listeners; even fewer runs needed to release memory after the binary:copy/1 introduction. * edoc * just ok * fun police * monitor parent and terminate if parent dies
[4.3] KZ00-41: handle number delete conflicts (2600hz#6285) * [4.3] KZ00-41: handle number delete conflicts Previously, when deleting the number document from the account database, a conflict almost always occurred on the first delete attempt as the number doc from the number database was used (which contained a different _rev). However, `knm_phone_number:retry_conflicts/4` only had code for saving to the target database (the account). The result is that the number doc (now in the "available" state) would be `ensure_saved` to the account database, resulting in number listings for the account to both show the number belonging to the account *and* show it as "available", an internal state that clients should not see. This changeset provides additional context to handle_bulk_change about what type of change, 'delete' or 'save', and informs retry_conflicts of how to proceed. Secondly, the likelyhood of conflict is high when saving/deleting from the account database as the JSON object used is the number db's version. `try_delete_from` has been updated to use just the number as ID and lets kz_datamgr build the tombstone and delete accordingly. * use macro-ized db_exists * just assert the truth * no need to be so loud
[4.3] HELP-12897: properly paginate directory's users (2600hz#6268) * [4.3] HELP-12897: properly paginate directory's users Prior, the view only indexed by the directory IDs on a user's doc. When `paginate=false` was included on a fetch of the directory, the directory/users_listing view did not interact nicely with the internal pagination protections added. The view arguments used `[{key, DirectoryId}, {limit, 50}]`; the first page would be returned and since the next `startkey` would be `DirectoryId` again, crossbar_doc gets stuck in a loop as there was no way to "increment" the startkey. Instead, the view now emits `[DirectoryId, UserId]` to allow differentiation between rows, and view options are now passed in as `[{startkey, [DirectoryId]}]`. This plays much nicer with pagination regardless of whether pagination has been disabled or not.
PreviousNext