* Memory leak in makeMutex - Promise never gets garbage collected
Hey, I've been debugging a memory leak in my application and traced it back to the makeMutex implementation.
The current implementation chains promises indefinitely without ever breaking the chain:
Every call to mutex() creates a new Promise that awaits the previous task, then becomes the new task. The problem is the old promises never get released because each one holds a reference to the previous through the closure.
What I found
Took a heap snapshot after running for a while and found hundreds of Promises from make-mutex.js holding ~15MB and growing. The retainer graph shows a long chain of Promises all pointing back to each other.
Since processingMutex handles every incoming message/notification, this chain grows constantly and never shrinks.
This keeps the same mutex behavior but lets the GC clean up old promises every 50 tasks instead of holding them forever.
* Refactor makeMutex to use AsyncMutex directly
* lint
* revert
* refactor: reorganize browser utility functions and improve buffer handling
* fix: harden protobuf deserialization and clean up code
* refactor: simplify data handling in GroupCipher and SenderKey classes
* fix: Ensure consistent Buffer hydration and remove redundant code
* refactor: update decodeAndHydrate calls to use proto types for improved type safety
* fix: handle invalid signatureKeyPublic types in sender-key-state
- added extra check to ensure signatureKeyPublic is either a base64 string or a Buffer
- fallback to empty buffer when unexpected object type is received
- prevents ERR_INVALID_ARG_TYPE error in Buffer.from
* adjusted based on @jlucaso1 recommmendation
* fix: handle chain key objects for skmsg group message decryption
previously, some sender chain keys were stored or retrieved as plain objects
(e.g. { '0': 85, '1': 100, ... }) instead of Buffers. this caused
"ERR_INVALID_ARG_TYPE" during initial decryption of skmsg group messages.
this fixes any chain key object is converted to a proper Buffer
before being passed to SenderChainKey.
* fix: add more robust checks and fallbacks
* feat: async cache
feat: async caching
* fix: linting issues
* fix: mget logic
---------
Co-authored-by: αѕтяσχ11 <devastro0010@gmail.com>
* fix: handle invalid signatureKeyPublic types in sender-key-state
- added extra check to ensure signatureKeyPublic is either a base64 string or a Buffer
- fallback to empty buffer when unexpected object type is received
- prevents ERR_INVALID_ARG_TYPE error in Buffer.from
* fix: lint
* adjusted based on @jlucaso1 recommmendation
* fix: handle chain key objects for skmsg group message decryption
previously, some sender chain keys were stored or retrieved as plain objects
(e.g. { '0': 85, '1': 100, ... }) instead of Buffers. this caused
"ERR_INVALID_ARG_TYPE" during initial decryption of skmsg group messages.
this fixes any chain key object is converted to a proper Buffer
before being passed to SenderChainKey.
* fix: add more robust checks and fallbacks
* hacky fix(sender-key-state): normalize signing pubkey as Buffer with 0x05 prefix
a little hacky fix that ensures getSigningKeyPublic always returns a proper Buffer to satisfy libsignal.
adds a fallback to prepend 0x05 when only a 32-byte key is present, avoiding
"Invalid public key" errors and TS type issues around Uint8Array vs Buffer.
* lid-mapping: get missing lid from usync
* lid-mapping, jid-utils: change to isPnUser and store multiple mappings
* process-message: parse protocolMsg mapping, and store from new msgs
* types: lid-mapping event, addressing enum, alt, contact, group types
* validate, decode: use lid for identity, better logic
* lid: final commit
* linting
* linting
* linting
* linting
* misc: fix testing and also remove version json
* lint: IDE fucking up lint
* lid-mapping: fix build error on NPM
* message-retry: fix proto import
Luiz Braga