lonnymq 0.0.20 → 0.0.22

package/README.md

@@ -180,36 +180,6 @@ When deferring a message, you can optionally specify `delayMs` and `state` argum
 
 **Note:** The above shows just one processing pattern (defer on failure with retry limits). You have complete flexibility in how you handle message processing - you might delete messages immediately, defer them unconditionally, implement different retry strategies based on error types, or use the message metadata (attempts, state, channel) to make sophisticated routing decisions.
 
-### Message Heartbeats
-
-For long-running message processing, you can use the heartbeat functionality to extend the lock time beyond the initial `lockMs` value. This is useful when you need to process a message for longer than originally anticipated but want to keep a shorter default lock time for faster recovery.
-
-```typescript
-const dequeueResult = await queue.dequeue({ databaseClient })
-
-if (dequeueResult.resultType === "MESSAGE_DEQUEUED") {
-    const { message } = dequeueResult
-    
-    // Start a long-running process
-    const intervalId = setInterval(async () => {
-        // Send heartbeat every 10 seconds to keep the message locked
-        await message.heartbeat({ databaseClient })
-    }, 10000)
-    
-    try {
-        // Process the message (this might take a long time)
-        await longRunningProcessMessage(message.content)
-        await message.delete({ databaseClient })
-    } catch (error) {
-        await message.defer({ databaseClient, delayMs: 30000 })
-    } finally {
-        clearInterval(intervalId)
-    }
-}
-```
-
-Heartbeats reset the unlock time to the current time plus the original `lockMs` value.
-
 ### Graceful Shutdowns and Message Recovery
 
 If your program ends unexpectedly, messages that are currently being processed may become "orphaned" in a locked state - causing channel blockages and reducing throughput. To mitigate this problem, it's essential that you shut down gracefully by catching unhandled exceptions and signals (i.e., `SIGINT`/`SIGTERM`) and finalize all outstanding messages before exiting.
@@ -282,7 +252,7 @@ await wait(messageId)
 
 ## Deadlocks
 
-If all queue actions are isolated to their own transaction, there is zero risk of deadlocks occurring. That being said, it is *possible* to safely bulk-perform the following actions within a single transaction if we ensure they are performed in a consistent lexicographical ordering with respect to channel name:
+If all queue actions are isolated to their own transaction, there is zero risk of deadlocks occurring. That being said, it is *possible* to safely bulk-perform the following actions within a single transaction if we ensure they are performed in a consistent ordering with respect to the target channel name:
 
 - Message create
 - Channel policy set  
@@ -293,42 +263,6 @@ Beyond the actions specified above, it is manifestly **unsafe** to bulk-perform
 - Message dequeue
 - Message defer
 - Message delete
-- Message heartbeat
-
-## Batching Operations
-
-When you need to perform multiple safe operations (message creation and channel policy changes) within a single transaction, LonnyMQ provides a batching mechanism that automatically handles proper ordering to prevent deadlocks.
-
-The batch interface mirrors a subset of the queue interface, supporting only the operations that are safe to perform together: message creation and channel policy management.
-
-```typescript
-const batch = queue.batch()
-
-// Create messages (assigned to random channels)
-batch.message.create({ 
-    content: Buffer.from("Welcome email"),
-    lockMs: 30000
-})
-
-// Create messages on specific channels
-batch.channel("user-notifications").message.create({ 
-    content: Buffer.from("User signup notification"),
-    lockMs: 60000
-})
-
-// Set channel policies
-batch.channel("high-priority").policy.set({
-    maxConcurrency: 5,
-    releaseIntervalMs: 100
-})
-
-// Clear channel policies  
-batch.channel("analytics").policy.clear()
-
-await batch.execute({ databaseClient })
-```
-
-The batch system ensures all operations are executed in a consistent lexicographical order, eliminating the possibility of deadlocks when multiple workers are performing bulk operations simultaneously.
 
 ## Database Clients