Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Test-only override of the usage feed's safety lag, and a test of its 60 s default

Open
  • Is something wrong?
#393 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
45/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
api, testing

Research direction

Start with USAGE_SAFETY_LAG_MS in app/src/operator-api/contract.ts and the validated usageSafetyLagMs argument of createOperatorApi in api.ts, then read how ALLOW_TEST_GITHUB_ENDPOINTS and ALLOW_TEST_LLM_ENDPOINTS are guarded. Read the feed section of app/src/usage/README.md before changing anything. Done when the override is read only behind the guard, refused in production without it, and tests T01 to T07 pass, including the 59 s and 61 s checks in the integration tests and the limited-workspace e2e journey.

Written by the indexing model from the issue text.

Description

area: app type: chore

Follow-up of #285 (low priority, not part of #268).

Problem

The usage feed of the operator API serves a settlement only once it is more than 60 seconds old (USAGE_SAFETY_LAG_MS in app/src/operator-api/contract.ts). That is right for production: it keeps two settlements that commit in the reverse order of their stamps from being skipped by a reader that moved on (app/src/usage/README.md, "The feed and the safety lag").

Two things follow:

  • The end-to-end journey of a limited workspace (app/e2e/operator/limited-workspace.e2e.ts, #285) has to wait for the lag twice, about 50 seconds each time, because the app is a separate process and the lag cannot be changed. Every full e2e run pays it.
  • Nothing proves at a level below the journey that the 60 seconds themselves are what the app uses: the integration tests inject a smaller usageSafetyLagMs, and the constant is only read in one place.

Proposed change

  1. Test-only override. createOperatorApi already takes a validated usageSafetyLagMs (api.ts). Add a path from the environment to it that works only where test endpoints are allowed, guarded like ALLOW_TEST_GITHUB_ENDPOINTS and ALLOW_TEST_LLM_ENDPOINTS: a variable with the lag in milliseconds (the existing validation, 1 second to 1 hour, applies), ignored with one log line unless the guard variable is true, and refused at start in a production deployment that sets it without the guard. No change for an instance that does not set either.
  2. Use it in the journeys of app/e2e/operator/ that wait for the feed (pollUsage), with a lag of a few seconds, and keep the journey's statement about the real default in a lower-level test (below).
  3. A lower-level test of the default. The route file built with no override uses USAGE_SAFETY_LAG_MS (60 seconds): a record settled 59 seconds ago is not served and one settled 61 seconds ago is, with a clock the test moves.

Out of scope: changing the default lag, serving unsettled records, anything about cursors.

Test cases

ID kind level case expected
T01 regression integration the operator API is made with no override a record settled 59 s ago is not served, one settled 61 s ago is (the default of 60 s)
T02 behavior unit the override variable is set with the test-endpoints guard on the lag is the value of the variable
T03 behavior unit the override variable is set without the guard the default applies, one log line says the override is ignored
T04 behavior unit the override is below 1 second, above 1 hour or not a number refused with the same code as the injected lag today; the default is not used silently
T05 behavior integration no override variable, no guard nothing changes: the feed behaves as in T01
T06 behavior e2e the journey of a limited workspace with the override the feed holds the settled records within a few seconds of their settlement; the privacy search and the order of the records are unchanged
T07 security integration the guard variable is not set in a production deployment the override cannot be reached, whatever the lag variable says
Dominant language
TypeScript
Stars
0
Forks
1
Avg merge
1h 15m
Merged PRs (30d)
217

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ExpidetGames/code-reviewer

All issues in ExpidetGames/code-reviewer

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.