@anterior/brrr 0.1.212 → 0.1.213
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/README.md +3 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -136,7 +136,9 @@ Additionally, there is no agent. Brrr works on the assumption that you can bring
|
|
|
136
136
|
|
|
137
137
|
The guarantees offered by these implementations are surfaced to the application layer. If your k/v store is write-after-write consistent, your application will have a consistent view of the call graph. If your store is eventually consistent, you may get contradicting results about dependents’ return values when a task is re-executed. This trade-off is yours to make.
|
|
138
138
|
|
|
139
|
-
Finally, brrr has _0 or more delivery guarantee_. To give brrr a once-or-more delivery, put it behind a job queue which has that capability. E.g.: SQS.
|
|
139
|
+
Finally, brrr has _0 or more delivery guarantee_. To give brrr a once-or-more delivery, put it behind a job queue which has that capability. E.g.: SQS.
|
|
140
|
+
|
|
141
|
+
Using a queue with at-least-once delivery as the brrr queue itself is _not_ enough to make the entire system at-least-once delivery: brrr does not carry around receipt handles for internal messages.
|
|
140
142
|
|
|
141
143
|
## Topics
|
|
142
144
|
|