Reset Limit
Overview
Limit Route Reset manually clears a rate limit lock created by the Limit Route stage, allowing immediate re-execution before the time window expires. It acts as a manual reset button for rate limits.
Where to find it: Flow Control in the stage library.
Configuration
Required Fields
| Field | Description | Example |
|---|---|---|
| Limit Name | Name of the limit to reset (must match Limit Route stage exactly) | email_sent_{{userId}}, api_batch_lock |
Using functions in these fields: Any value field above accepts @ functions, for example @NowSecond for the current time or @calc(...) for a calculation.
See Flows Functions for the full list.
Exit Points
| Exit | When | Flow Direction |
|---|---|---|
| Pass | Always (even if limit doesn't exist) | ✓ Reset command executed, flow continues |
How It Works
When executed, Limit Route Reset:
- Resolves the limit name - Gets name from configuration (must match Limit Route exactly)
- Deletes the lock - Removes rate limit from distributed storage if it exists
- Always returns Pass - Idempotent operation; succeeds regardless of whether lock existed
Important: This stage provides no confirmation whether a lock was actually removed. It always succeeds, making it safe to call multiple times.
Common Use Cases
1. Admin Override for User Cooldown
- Scenario: Users claim reward once per day, admin can reset
- Limit Name:
reward_claimed_{{userId}} - Flow: Admin verification → Reset → Return "Cooldown reset"
- Result: User can claim again immediately
2. Reset After Successful Completion
- Scenario: API batch locked for 5 minutes, reset after completion
- Limit Name:
api_batch_lock - Flow: Process batch → Reset lock on success
- Result: Next batch can start immediately (not waiting remaining time)
3. Cancel Operation Clears Lock
- Scenario: User starts operation, then cancels
- Limit Name:
operation_{{userId}} - Flow: Cancel endpoint → Reset → Return "Cancelled"
- Result: User can start again immediately
4. Premium User Bypass
- Scenario: Free users rate limited, premium users bypass
- Limit Name:
export_{{userId}} - Flow: Limit Route Fail → Check premium status → Reset → Continue
- Result: Premium users never blocked by rate limits
5. Conditional Reset After Error
- Scenario: API rate limit error, retry after clearing lock
- Limit Name:
api_lock - Flow: Error 429 → Wait 60s → Reset → Retry
- Result: Smart retry after rate limit errors
6. Scheduled Reset (Nightly Cleanup)
- Scenario: Reset all user limits at midnight
- Flow: Scheduler trigger → Loop users → Reset
daily_limit_{{userId}} - Result: Fresh start for new day
Key Behaviors
| Feature | Behavior |
|---|---|
| Exact Name Match Required | Must exactly match Limit Route stage's name (case-sensitive) |
| Idempotent Operation | ✓ Safe to call multiple times; no error if limit doesn't exist |
| No Confirmation | No return value indicating whether lock was actually removed |
| No Undo | Once reset, the limit is cleared; cannot restore a cleared limit |
| Immediate Effect | Next Limit Route execution will Pass and create new lock |
| Workspace Scoped | Can only reset limits within same workspace |
Best Practices
- ✓ Always use explicit Limit Names (don't rely on defaults when using Reset)
- ✓ Match names exactly between Limit Route and Reset (case-sensitive)
- ✓ Use same variables in both stages (e.g.,
{{userId}}) - ✓ Verify user permissions before allowing reset (security check)
- ✓ Log reset actions for audit trail and monitoring
- ✓ Test reset behavior to verify limit actually clears
- ✓ Use sparingly - frequent resets defeat purpose of rate limiting
- ✓ Combine with conditions (reset only when appropriate)
- ✓ Document use cases explaining when reset is appropriate
Common Mistakes
| Mistake | Symptom | Fix |
|---|---|---|
| Using default Limit Names | Reset doesn't clear the lock | Limit Route and Reset have different stage IDs; use explicit names |
| Typo in Limit Name | Lock not reset | Copy exact name from Limit Route; use constants or variables |
| Variable name mismatch | Different locks cleared | Ensure {{userId}} vs {{userID}} matches exactly |
| Expecting confirmation | Unclear if reset worked | Reset always succeeds; no way to know if lock existed |
| Security oversight | Unauthorized users reset limits | Add authorization checks before reset stage |
| Resetting too frequently | Rate limiting ineffective | Review reset conditions; ensure they're exceptional cases |
Troubleshooting
| Issue | Exit/Result | Common Cause | Fix |
|---|---|---|---|
| Reset doesn't clear limit | Pass (but no effect) | Limit Name doesn't match Limit Route exactly | Verify spelling and variable names match exactly |
| Wrong limit cleared | Pass | Variables resolve to different values | Ensure variables have same values in both stages |
| No effect on other flows | Pass | Different Limit Names or workspace | Use same Limit Name across flows to share limits |
| Reset fails silently | Pass | Connection errors to distributed storage | Check system logs for errors |
Edge Cases
- Resetting non-existent limit: Succeeds with no effect; no error thrown
- Resetting expired limit: Lock already gone; reset has no effect
- Wrong Limit Name: Silently succeeds; check spelling and variables
- Reset before Limit Route: No effect; next Limit Route still creates lock
- Multiple resets: Safe and idempotent; subsequent calls do nothing
- Variable mismatch:
{{userId}}vs{{userID}}create different keys - Default Limit Name issue: Limit Route and Reset have different stage IDs, won't match
Related Stages
- Limit Route: Creates the rate limit lock that this stage resets
- Route Flow: Add conditions before resetting
- Loop: Reset multiple limits in batch