fix: LaserStream-triggered gatedLiquidate calls no longer consume per-owner cap slots - #361
fix: LaserStream-triggered gatedLiquidate calls no longer consume per-owner cap slots#361Ayomisco wants to merge 1 commit into
Conversation
…-owner cap slots
The per-cycle MAX_LIQ_PER_OWNER_PER_CYCLE=3 cap in _cycleOwnerCounts was shared
between the polling scan and the LaserStream event path. A burst of LaserStream
events for three distinct positions of the same owner could exhaust the owner cap
before the polling scan reached a fourth underwater position, causing it to be
skipped for the cycle.
Add a source ("polling" | "laserstream") parameter to gatedLiquidate(). Only
polling-path calls increment _cycleOwnerCounts. Event-driven calls are still
deduplicated by _cycleSeenPositions and _inFlightPositions, preventing double
liquidation, but they no longer block the polling path from exercising the cap.
|
Warning Review limit reached
More reviews will be available in 27 minutes and 39 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Closes #360
What
Add a
source: "polling" | "laserstream"parameter togatedLiquidate()and apply the per-owner cycle cap only on polling calls.Why
MAX_LIQ_PER_OWNER_PER_CYCLE = 3bounds how many of a single owner's positions the polling scan can liquidate in one cycle. LaserStream fires one event per position. Both paths shared the same_cycleOwnerCountsmap, so a burst of LaserStream events exhausted the polling cap and blocked valid liquidations for that owner in the same window.LaserStream calls are already protected against duplicates by
_cycleSeenPositionsand_inFlightPositions, so they do not need the polling cap.Changes
src/services/liquidation.ts: addedsourceparameter togatedLiquidate(). Owner-count check and increment wrapped inif (source === "polling"). LaserStream call site passes"laserstream".