@beignet/provider-locks-redis 0.0.32 → 0.0.33

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -1,5 +1,11 @@
1
1
  # @beignet/provider-locks-redis
2
2
 
3
+ ## 0.0.33
4
+
5
+ ### Patch Changes
6
+
7
+ - c6c4434: Add live Redis coverage for lock contention, fencing, stale owners, bounded waits, and timeouts, with explicit topology limits.
8
+
3
9
  ## 0.0.32
4
10
 
5
11
  ### Patch Changes
package/README.md CHANGED
@@ -117,12 +117,28 @@ Use app-owned fake locks or an in-memory `LocksPort` in use-case tests when
117
117
  lease behavior is not the subject of the test. Use `createRedisLocks(...)` with
118
118
  a test Redis client for provider-level tests that need Lua/fencing semantics.
119
119
 
120
+ This package also includes an opt-in live Redis suite. It uses independent
121
+ Redis connections to exercise concurrent acquisition, monotonic fencing,
122
+ expired-owner rejection, bounded waiting, and timeouts. The default
123
+ `bun run test` command remains hermetic. Set `REDIS_LOCKS_TEST_URL` or the
124
+ shared `REDIS_TEST_URL` for the live suite:
125
+
126
+ ```bash
127
+ REDIS_LOCKS_TEST_URL=redis://localhost:6379 bun run test:live
128
+ ```
129
+
120
130
  ## Deployment notes
121
131
 
122
- Use a Redis deployment with persistence and predictable latency for work that
123
- depends on lease timing. Locks reduce duplicate work but do not replace
124
- database transactions, unique constraints, idempotency keys, or outbox claim
125
- state for business correctness.
132
+ Use a single Redis primary with persistence and predictable latency for work
133
+ that depends on lease timing. The provider's two-key Lua acquisition does not
134
+ currently support Redis Cluster. Primary failover with asynchronous replication
135
+ can lose recent lease or fencing-counter writes, and the live suite does not
136
+ simulate failover or network partitions.
137
+
138
+ Fencing tokens become a correctness boundary only when the protected durable
139
+ resource atomically accepts tokens strictly greater than the last token it
140
+ observed. Without that downstream check, use the lease to reduce duplicate
141
+ work, not to prove that duplicates are impossible.
126
142
 
127
143
  ## Correctness note
128
144
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@beignet/provider-locks-redis",
3
- "version": "0.0.32",
3
+ "version": "0.0.33",
4
4
  "type": "module",
5
5
  "description": "Redis-backed lock and lease provider for Beignet",
6
6
  "main": "./dist/index.js",
@@ -25,8 +25,9 @@
25
25
  "prepack": "bun run build",
26
26
  "dev": "tsc --watch",
27
27
  "clean": "rm -rf dist coverage .turbo",
28
- "test": "bun test",
29
- "test:coverage": "bun test --coverage",
28
+ "test": "bun test src/index.test.ts",
29
+ "test:live": "bun test src/redis-live.test.ts",
30
+ "test:coverage": "bun test --coverage src/index.test.ts",
30
31
  "lint": "biome check ."
31
32
  },
32
33
  "keywords": [