Repository navigation
perf(core): recheck the shared trust file once per interval, not per read - #436
Conversation
…read Every directory entry a node merges asks the trust boundary several questions, and each question stat()ed the shared trust file to see whether another process had replaced it. On a node serving a large local mesh that was thousands of stats a second. Reads now rest on the last look for TRUST_FILE_RECHECK_INTERVAL_MS, paced by an injected clock, which bounds how long another process's revocation can go unseen by a read. Writes still re-read first, since each rewrites the whole file and must not erase another process's change. GatewayTrust takes its location and clock as one options object.
|
@codex security review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
This security review couldn’t start because the paying account has exhausted its Codex allowance and has insufficient available credits. The payer can check their balance and add credits in the Codex usage dashboard, then try again. If you do not manage the paying account, contact this repository's admins. |
1 similar comment
|
This security review couldn’t start because the paying account has exhausted its Codex allowance and has insufficient available credits. The payer can check their balance and add credits in the Codex usage dashboard, then try again. If you do not manage the paying account, contact this repository's admins. |
|
🎉 This PR is included in version 8.15.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Every directory entry a node merges asks the trust boundary several questions (
isTrusted,isTrustedPrincipal,isVouchedBy,hasAny), and each onestated the shared trust file to see whether another process had replaced it. A profile of a busy hub process showed that at several thousandstats a second (#434).Reads now rest on the last look at the file for
TRUST_FILE_RECHECK_INTERVAL_MS, paced by an injected clock. That interval is the longest another process's revocation can go unseen by a read; I chose one second because a hub-only device already stays in the directory until the next presence re-advertisement, so the bound adds no delay to that path. Writes still re-read first, since each rewrites the whole file and would otherwise erase another process's change. The four existing tests that relied on instant cross-instance visibility now advance a manual clock past the interval.GatewayTrustnow takes{ location, clock }as one options object, which the lint rule on trailing optional parameters asked for; the only production caller isMeshStore.The new tests count looks at the file through an injected clock, not time: reads inside an interval cost none, one look per interval after it, a revocation seen once the interval passes and not before. With the throttle removed three of the four fail.
Refs #434