Faucet: Limit usage to once per time window, increase quantity, and return the remaining wait time in case of a rate limit error.

[GabrielMartinezRodriguez]

Description

Faucet: Limit usage to once per time window, increase quantity, and return the remaining wait time in case of a rate limit error

• Include all relevant context (but no need to repeat the issue's content).
• Draw attention to new, noteworthy & unintuitive elements.

Toggle Checklist

Checklist

Basics

• B1. I have applied the proper label & proper branch name (e.g. norswap/build-system-caching).
• B2. This PR is not so big that it should be split & addresses only one concern.
• B3. The PR targets the lowest branch it can (ideally master).

Reminder: PR review guidelines

Correctness

• C1. Builds and passes tests.
• C2. The code is properly parameterized & compatible with different environments (e.g. local,
  testnet, mainnet, standalone wallet, ...).
• C3. I have manually tested my changes & connected features.

< INDICATE BROWSER, DEMO APP & OTHER ENV DETAILS USED FOR TESTING HERE >

< INDICATE TESTED SCENARIOS (USER INTERFACE INTERACTION, CODE FLOWS) HERE >

• C4. I have performed a thorough self-review of my code after submitting the PR,
  and have updated the code & comments accordingly.

Architecture & Documentation

• D1. I made it easy to reason locally about the code, by (1) using proper abstraction boundaries,
  (2) commenting these boundaries correctly, (3) adding inline comments for context when needed.
• D2. All public-facing APIs are documented in the docs.
  Public APIS and meaningful (non-local) internal APIs are properly documented in code comments.
• D3. If appropriate, the general architecture of the code is documented in a code comment or
  in a Markdown document.
• D4. An appropriate Changeset has been generated (and committed) with make changeset for
  breaking and meaningful changes in packages (not required for cleanups & refactors).

[cloudflare-workers-and-pages]

Deploying happychain with    Cloudflare Pages

Latest commit:	eea769e
Status:	⚡️  Build in progress...

View logs

[GabrielMartinezRodriguez]

• Faucet: Limit usage to once per time window, increase quantity, and return the remaining wait time in case of a rate limit error. #727 👈 (View in Graphite)
• feat(faucet): wait tx inclusion #720
• feat(txm): added txm callbacks and promises when tx status change #719
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[aodhgan]

cute little package! claude is telling me that this code will cover "most" cases though:

const unit = {
    ms: 1,
    s: 1e3,
    m: 60e3,
    h: 3_600e3,
    d: 86_400e3,
  } as const;
  
export function formatMs(ms: number, long = false): string {
    const abs = Math.abs(ms);
    for (const [abbr, size] of Object.entries(unit).reverse()) {
        if (abs >= size) {
        const val = Math.round(ms / size);
        return long ? `${val} ${abbr}${Math.abs(val) !== 1 ? 's' : ''}` : `${val}${abbr}`;
        }
    }
    return `${ms}ms`;
}

so im not sure if its worth the import? security risks (minimized by bun to be fair), 4kb package bloat (lol) to a backend service. not a hill i will die on

[GabrielMartinezRodriguez]

changed 👍

[aodhgan]

is there a way this can be negative?

[aodhgan]

i think we might be missing an if(timeToWait>0)... ?

[GabrielMartinezRodriguez]

It cannot be negative because, if it were, that would mean the request occurred before the time window, and we're only processing requests within the time window

[norswap]

So the reason is that the DB doesn't store uses longer than the window? This definitely could use a comment, and to be honest, a check wouldn't be a bad idea anyway just in case. e.g. if the service crashes, stays down for some time, then loads before the first prune can go through, the scenario of a negative number seems possible.

[GabrielMartinezRodriguez]

done