atomesh: make the fan-out request timeout a CLI option (--worker-request-timeout-secs) by jgong5 · Pull Request #478 · jgong5/ATOM

jgong5 · 2026-09-29T01:44:15Z

Closes #469. Ready for review. No blocking issues.

The router's bound on its own /get_load and /flush_cache requests to workers was a compiled-in 5 s. It is now --worker-request-timeout-secs (default 5, at least 1). The 30 s DEFAULT_WORKER_HTTP_TIMEOUT_SECS bounds no request, so it stays a constant; the design text that says otherwise is #477.

Dev record

Found: WORKER_CLIENT makes one request, http_health_check, which sets its own timeout; in reqwest 0.12 that replaces the client default.
Found: atom/compass/audit/sync_sites.json pins atomesh lines by text, so three of its rows move with this change (outside the issue's file set, mechanical).
Decided: the value lives in a process-wide static read by request_timeout(), not in RouterConfig, so the last router config built in a process wins. It skips RouterConfig::validate(), so clap refuses 0 at parse time.
Surprised: policies::tree::tests::test_tree_structure_integrity_after_stress failed once in three full lib runs at the head, passed 5 of 5 alone; policies/ is untouched.
Left undone: the separate compiled-in 5 s /engine_metrics scrape bound (observability, on design: doc 01 names a 30 s atomesh bound that bounds no request (found in #469) #477); an end-to-end launch.

Named result

core::worker_manager::tests::worker_request_timeout_option_outlasts_a_40s_worker, a stub worker that answers after 40 s:

flags	`/get_load`	`/flush_cache`	elapsed
none	timed out, load -1	0 flushed	5.002 s
`--worker-request-timeout-secs 60`	load 7	1 flushed	40.002 s

worker_request_timeout_defaults_to_5s_and_refuses_zero pins the default of 5 and the refusal of 0.

Gates

branch @ 46ae9eb31: 5281 passed, 155 skipped, 3 xfailed, GATE_CPU_RC=0.
control @ f87413a7a: 5281 passed, 155 skipped, 3 xfailed, GATE_CPU_RC=0.
atomesh cargo test --lib: 1110 passed at the head, 1108 at the tip. clippy 81 warnings on both, none in changed lines. rustfmt clean. No Python file changed, so ruff has nothing to check.

Evidence

Revert-red at 46ae9eb31, one line-count-preserving mutant at a time, tree restored and compared after each. Node ids are under core::worker_manager::tests.

mutant	result	failing test / assertion
none	2 passed, 45.05 s	none
`to_router_config` stores the default, not the flag	FAILED, rc 101	`worker_request_timeout_option_outlasts_a_40s_worker`, `assert_eq!(loads.loads[0].load, ..)`, left -1 right 7 (option leg 5.001 s)
`fan_out` site back to `Duration::from_secs(5)`	FAILED, rc 101	same test, `assert_eq!(flush.successful.len(), ..)`, left 0 right 1
`parse_load_response` site back to `Duration::from_secs(5)`	FAILED, rc 101	same test, `assert_eq!(loads.loads[0].load, ..)`, left -1 right 7 (flush 1 at 40.002 s)
`value_parser` range removed (the attribute as it was at `b28823d9d`)	FAILED, rc 101	`worker_request_timeout_defaults_to_5s_and_refuses_zero`, `assertion failed: parse(&["--worker-request-timeout-secs", "0"]).is_err()`
`DEFAULT_WORKER_REQUEST_TIMEOUT_SECS` 5 to 30	FAILED, rc 101	`worker_request_timeout_defaults_to_5s_and_refuses_zero`, `assert_eq!(parse(&[]).unwrap().worker_request_timeout_secs, 5)`, left 30 right 5. The 40 s stub test alone passes this mutant (no-flag leg 30.002 s).

Inventory: with the tip's sync_sites.json in the branch tree, tests/compass/test_sync_inventory.py::test_anchor_lines_are_still_where_they_say fails with "no longer holds" for const REQUEST_TIMEOUT in worker_manager.rs, pub disable_health_check and pub disable_circuit_breaker in cliargs.rs; with the branch's json, 26 passed. Rows changed: the worker_manager.rs REQUEST_TIMEOUT row now points at pub worker_request_timeout_secs in cliargs.rs; the two cliargs.rs rows changed only line; the DEFAULT_WORKER_HTTP_TIMEOUT_SECS row changed only why. It keeps category C1, which now contradicts its why; recorded on #477.

reqwest check: a scratch /health stub answering after 40 s with health_config.timeout_secs = 60 gave http_health_check() -> ok=true after 40.047 s, so the 30 s client default did not apply.

Stress-test flake: 3 full lib runs at 46ae9eb31 gave 1109 passed / 1 failed (test_tree_structure_integrity_after_stress, "Tenant should have positive size"), then 1110 and 1110 passed. The tip gave 1108 passed twice.

Cost vs an estimate of about 30 statements: about 33 statements (production: const, static, fn, CLI field and its to_router_config store; tests: 22 statements over two fns), counted by hand because the AST counter is Python-only. Physical lines +109/-13: worker_manager.rs +91/-4 (tests 70 of them), cliargs.rs +11/-2, sync_sites.json +7/-7. The 3.3x physical-to-statement ratio comes from rustfmt's multi-line use blocks and the axum builder chain in the stub.

🤖 Generated with Claude Code

WorkerManager's /get_load and /flush_cache requests carried a compiled-in 5 s timeout. It is now --worker-request-timeout-secs, default 5, so a run whose workers answer on a slower clock can raise it. Routing policy code is untouched. The other constant the issue names, DEFAULT_WORKER_HTTP_TIMEOUT_SECS (30 s), is left alone: its client serves only the HTTP health check, and that request sets its own timeout from --health-check-timeout-secs, which replaces the client default. A 40 s health check with a 60 s health timeout succeeds, so the 30 s value bounds no request and an option for it would change nothing. The sync inventory rows that pin cliargs.rs lines move with the new field, the worker_manager.rs row now points at the option, and the worker.rs row states what that client actually bounds. Test: a stub worker that answers after 40 s. Without the option both requests time out at 5.0 s; with --worker-request-timeout-secs 60 both succeed at 40.0 s. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

jgong5 · 2026-09-29T01:59:05Z

    pub request_timeout_secs: u64,

+    /// Timeout in seconds for the router's own /get_load and /flush_cache requests to workers
+    #[arg(long, default_value_t = DEFAULT_WORKER_REQUEST_TIMEOUT_SECS, help_heading = "Request Handling")]


Required finding 1: --worker-request-timeout-secs 0 is accepted and silently turns off load reporting and cache flushes. Fix: add value_parser = clap::value_parser!(u64).range(1..) to this #[arg], and pin CliArgs::try_parse_from(["atomesh", "--worker-request-timeout-secs", "0"]).is_err(), which needs no stub and no wall time.

Probe at b28823d9d and why

A zero Duration makes reqwest's total-timeout future ready on its first poll, so every /get_load and /flush_cache request fails before the worker can answer. Scratch probe, not committed and removed: a stub /get_load that answers immediately.

flag parse_from RouterConfig::validate() load

--worker-request-timeout-secs 5 ok ok 7

--worker-request-timeout-secs 0 ok ok -1

The option beside it, request_timeout_secs, refuses zero with "Must be > 0" (validate_server_settings in config/validation.rs); this option cannot reach that check, because it is not in RouterConfig. Zero is also the value a user of a simulated launch is most likely to try for "no bound", and it does the opposite (a refusal is due, not a fallback).

jgong5 · 2026-09-29T01:59:07Z

+            );
+            assert_eq!(loads.loads[0].load, if answered { 7 } else { -1 });
+            assert_eq!(flush.successful.len(), answered as usize);
+            assert_eq!(elapsed >= slow, answered);


Required finding 2: "defaults unchanged" is pinned only for a default of 40 s or more, because the no-flag leg's only time bound is elapsed < 40 s; the body's M4 row ("a changed default") overstates it. Fix, one line: assert!(answered || elapsed < Duration::from_secs(10)); (the leg measured 5.002 s), or assert CliArgs::parse_from(["atomesh"]).worker_request_timeout_secs == 5. Either reddens on the 5 -> 30 mutant; please record that red.

The mutant

DEFAULT_WORKER_REQUEST_TIMEOUT_SECS: u64 = 5 -> 30, one line, nothing else changed, line counts 849/415:

published: 1 passed, 45.05 s (no-flag leg 5.002 s)

mutant: 1 passed, 70.05 s (no-flag leg 30.002 s, load -1, 0 flushed)

jgong5 · 2026-09-29T01:59:08Z

+
+/// Timeout for the `/flush_cache` and `/get_load` requests below; set from
+/// `--worker-request-timeout-secs` when the router config is built.
+pub static WORKER_REQUEST_TIMEOUT_SECS: AtomicU64 =


Reservation, not blocking: the process-wide static is acceptable and the leaner choice. Suggestion: one comment line on the static naming the ceiling, e.g. "process-wide: the last router config built wins; move into RouterConfig if a process ever builds two."

What the alternative costs, and the static's costs, at this head

Moving the value into RouterConfig would touch config/types.rs, server.rs (two call sites) and app_context.rs (LoadMonitor::new), and change the signatures of flush_cache_all, get_all_worker_loads and LoadMonitor: about 20 lines in 3 more files, no difference in behaviour. Simplicity outweighs a cleaner abstraction at that price.

It skips RouterConfig::validate(); finding 1 fixes that at the clap layer.

The last to_router_config in a process wins. Today there is one caller per process: main in main.rs, and build_server_config in python.rs once per launch path in atom/entrypoints/atomesh/server.py.

The test leaves the static at 60 for the rest of the lib test process. No other lib test calls to_router_config or the fan-out functions, so nothing reads it.

jgong5 · 2026-09-29T01:59:09Z

@@ -2483,27 +2483,27 @@
   "anchor": "pub const DEFAULT_WORKER_HTTP_TIMEOUT_SECS",
   "category": "C1",


Reservation, not blocking, and a landing-order note. This row keeps category C1 while its new, correct why says it bounds no request; changing the category changes the audit README counts, outside this PR, so it is recorded on #477. This file conflicts with #476: whichever lands second must keep this PR's file/line/anchor/why on all four rows and add #476's mechanism fields.

Detail

Category: the audit README defines C1 as "a bound that exists to declare something broken: raise it, or switch it off", and counts the row in "five router and server bounds". The why is correct: the client has one use (http_health_check), and reqwest 0.12.28 RequestConfig::fetch returns the request's timeout and falls back to the client default only when the request has none, so it replaces the default rather than taking the minimum.

Conflict: git merge-tree --write-tree 67117f738 b28823d9d reports CONFLICT (content) here. #476 (delivers #454) still has worker_manager.rs:24 const REQUEST_TIMEOUT and cliargs.rs:423/:398 on these rows, and gives this row mechanism: K8. #476 carries need human, so this PR will most likely land first, and #476's base-update merge must do the keeping. If it keeps #476's line numbers, test_anchor_lines_are_still_where_they_say fails with exactly the three messages recorded in this PR's body. K8 on this row needs a second look for the same reason as the category.

jgong5 · 2026-09-29T01:59:11Z

REQUEST CHANGES at b28823d9df1558c8a638b516d66721c7b97c157c: 2 blocking. Round 1, reviewer agent, base f87413a7a. Both findings are inline.

--worker-request-timeout-secs 0 is accepted and silently disables /get_load and /flush_cache (load -1 from a worker answering at once). Fix: value_parser!(u64).range(1..) on the #[arg], plus a try_parse_from(... "0") pin.
"Defaults unchanged" is not pinned below 40 s: default 5 -> 30 still passes, so the body's M4 row overstates it. Fix: bound the no-flag leg (e.g. < 10 s) or assert the parsed default is 5, and record the red.

Checked: the narrowing to one constant, the named result, revert-red M1-M3, the inventory rows, gate 1, the Rust suite, design references and effort; all hold (details).
Accepted with reservation: the process-wide static; the 40 s test in the default suite; the worker.rs:29 inventory row's category; landing order with #476 (details).
Watch next: the M4 launcher must pass a positive value; /engine_metrics has its own 5 s bound (noted on #477); test_load_counter_performance can fail under parallel load. The handoff on #469 should say only one of its "two bounds" became an option.

ponytail-review: lean already, no findings (details).

Verified

Narrowing: at this head WORKER_CLIENT has one use, http_health_check, and that request sets .timeout(health_config.timeout_secs). No other file names WORKER_CLIENT or DEFAULT_WORKER_HTTP_TIMEOUT_SECS. reqwest 0.12.28 (the only 0.12 in the registry; Cargo.toml asks for 0.12.8, no lockfile) resolves the total timeout in RequestConfig::fetch, which takes the request's value and falls back to the client's only when the request has none; the RequestBuilder::timeout doc says it "overrides the timeout configured using ClientBuilder::timeout()". So the 30 s default bounds no request. The developer's 40 s scratch test was not re-run, since the source settles it. design: doc 01 names a 30 s atomesh bound that bounds no request (found in #469) #477 is the right home for the D5 and D7 text of 01 and compass(design): doc 01 D4, D5, D9 and the decision log move to the PDES mechanisms #450's D5/D9 item 7.
Named result, gpu_docker jgong5_vllm, cargo 1.94.0: no flag gave load -1, 0 flushed, 5.002 s; --worker-request-timeout-secs 60 gave load 7, 1 flushed, 40.002 s. 1 passed, 45.05 s.

Revert-red, one mutant at a time, serially, line counts kept (849/415), nothing else changed, tree restored with git checkout and checked clean. Pre-fix sites from git show f87413a7a:atom/mesh/src/core/worker_manager.rs (REQUEST_TIMEOUT = 5 s and its two uses). M1-M3 each fail on the assertion naming their own site.

mutant	result	node id / assertion
none	1 passed, 45.05 s	none
M1 `to_router_config` stores the default	FAILED rc 101, 10.05 s	`core::worker_manager::tests::worker_request_timeout_option_outlasts_a_40s_worker`, the load assertion, left `-1` right `7` (option leg 5.001 s)
M2 `fan_out` site -> `Duration::from_secs(5)`	FAILED rc 101	same test, the flush assertion, left `0` right `1` (load 7 at 40.001 s)
M3 `parse_load_response` site -> `Duration::from_secs(5)`	FAILED rc 101	same test, the load assertion, left `-1` right `7` (flush 1 at 40.002 s)
M5 default const `5 -> 30`	1 passed, 70.05 s	none (finding 2)
null control: comment edit, same line count	1 passed, 45.05 s	none

Inventory: four rows changed, not three. Two changed only line (cliargs.rs 423 -> 430 and 398 -> 405; both texts are at those lines at the head). One was re-pointed (worker_manager.rs:24 -> cliargs.rs:334 pub worker_request_timeout_secs, new why). One changed only its why (worker.rs:29). Both why texts are accurate. On node 18 the head json gives 26 passed; the tip's json in the head tree gives 1 failed / 25 passed (tests/compass/test_sync_inventory.py::test_anchor_lines_are_still_where_they_say, the three "no longer holds" messages the body quotes). The file-set widening is mechanical and necessary.
Gate 1, node 18 xiaobizh_n18_cpu, each tree's own scripts/compass/gate_cpu.sh, unpiped, atom.__file__ resolved under each root: head b28823d9d and control f87413a7a both 5281 passed, 155 skipped, 3 xfailed, GATE_CPU_RC=0.
Rust lib suite at head: 1109 passed, rc 0, 51.40 s. One earlier full run gave 1108 passed / 1 failed on core::worker::tests::test_load_counter_performance (ops_per_sec > 1_000_000, a debug-build throughput floor); alone it passed 3 of 3 at about 1.9M ops/s, and it passed in the full-suite rerun. The test predates this PR, which does not touch worker.rs.
Design-doc references: none over the whole file set at the head.
ponytail-review: const + static + request_timeout() is the minimum for one value read at two sites, and one test covers both sites through one join!.
Effort: about 29 statements against about 30 (physical +95/-13, 3.2x, mostly rustfmt use blocks and the axum stub). Not an escalation by statement count.

Reservations, in full

Static vs RouterConfig: accepted (inline on worker_manager.rs). Threading the value through RouterConfig costs about 20 lines in 3 more files and changes no behaviour; its one real cost, skipping validate(), is covered by finding 1. Suggestion: a one-line comment naming the last-writer-wins ceiling.
The 40 s test belongs in the default suite; do not #[ignore] it. No automated job runs the atomesh lib suite: the only cargo test in .github/ is the mocker harness (atomesh-mocker-benchmark.yaml, on main), and the Compass gate is Python. Those who run this suite are those who touch atomesh, whom this pin is for; an ignored pin is one nobody sees fire. Cost: about 41 s of idle wall time, no extra CPU (suite 10 s -> 51.4 s).
worker.rs:29 row: it stays C1 ("raise it, or switch it off") while its why says it bounds no request, and compass(audit): a mechanism field (K1-K9) on every sync-inventory row, send_multipart in the scanner #476 labels the same row K8. Recorded on design: doc 01 names a 30 s atomesh bound that bounds no request (found in #469) #477 (inline on sync_sites.json).
Landing order with compass(audit): a mechanism field (K1-K9) on every sync-inventory row, send_multipart in the scanner #476 (delivers compass(audit): a mechanism field on every sync-inventory row, and the README table that classifies by it #454, need human): git merge-tree --write-tree 67117f738 b28823d9d reports CONFLICT (content) in sync_sites.json. Whichever lands second must keep this PR's line/anchor/why values on the four atomesh rows and compass(audit): a mechanism field (K1-K9) on every sync-inventory row, send_multipart in the scanner #476's mechanism fields.

Generated with Claude Code

…lt (#469) A zero timeout made every /get_load and /flush_cache request fail before the worker could answer, and nothing refused it. clap now rejects values below 1. A parse-only test pins the refusal and the default of 5, which the 40 s stub test held only against defaults of 40 s or more. The static's doc comment now says the last router config built in a process wins. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

jgong5 · 2026-09-30T06:47:12Z

Round 2 pushed 46ae9eb31. No blocking issues.

Zero timeout: clap now refuses it with value_parser!(u64).range(1..). Pin: worker_request_timeout_defaults_to_5s_and_refuses_zero; removing the range fails its is_err() assertion.
Default: the same test asserts the parsed default is 5. With the const set to 30 it fails, left 30 right 5.
Static: its doc comment now says the last router config built in a process wins.

Gate 5281 passed, rc 0, same as control. PR body updated.

jgong5 · 2026-09-30T07:03:55Z

Review round 2. Verdict: APPROVE at 46ae9eb317977b1a84aa34aec925042c6196ded6. Both round-1 findings are closed. No blocking issues.

Zero timeout: closed. With .range(1..) removed, worker_request_timeout_defaults_to_5s_and_refuses_zero fails on its is_err() assertion, and it is the only test that fails.
Default of 5: closed. With the const at 30, or 30 put back at the #[arg] site, the same test fails with left 30, right 5.

Checked: the CPU gate on the head's tree and on the tree that will land (head merged with the tip 0e16d3a98); each matches its control. The Rust lib suite at the head: 1110 passed. The delta has no design-doc references. ponytail-review: lean already.
Accepted with reservation: none new.
Watch next: #514, the pre-existing test_tree_structure_integrity_after_stress flake (27 of 500 runs alone at the tip). Also test_load_counter_performance, which failed its throughput floor in 3 of 15 full lib runs at the head. Both are outside this PR.

Evidence

Delta b28823d9d..46ae9eb31 is one commit with no merge: the value_parser range in cliargs.rs, and in worker_manager.rs one doc-comment line and the new test.

Revert-red at the head. One mutant at a time, serially, with line counts kept (849/429). Each runs the full cargo test --lib, and the tree is restored and checked clean afterwards. The node id is core::worker_manager::tests::worker_request_timeout_defaults_to_5s_and_refuses_zero in every red row.

mutant	result	assertion
none	1110 passed, rc 0	none
`.range(1..)` removed, `value_parser!(u64)` kept	1 failed / 1109 passed, rc 101	`parse(&["--worker-request-timeout-secs", "0"]).is_err()`
whole `value_parser` removed (the attribute as it was at `b28823d9d`)	1 failed / 1109 passed, rc 101	same
`DEFAULT_WORKER_REQUEST_TIMEOUT_SECS` 5 to 30	1 failed / 1109 passed, rc 101	`parse(&[])` default, left 30 right 5
const kept at 5, `default_value_t = 30` on the `#[arg]`	1 failed / 1109 passed, rc 101	same, left 30 right 5
null control: comment edit, same line count	1110 passed, rc 0	none

CPU gate on node 18 xiaobizh_n18_cpu, run with each tree's own scripts/compass (the same tree object on all three), rc unpiped:

head 46ae9eb31: 5281 passed, 155 skipped, 3 xfailed, GATE_CPU_RC=0.
merged: git merge-tree --write-tree 0e16d3a98 46ae9eb31 is clean and gives a9caec5b6, which is not the head tree 2e54b46dc. Gated as local commit 6b19cd597: 5213 passed, 155 skipped, 3 xfailed, GATE_CPU_RC=0.
control, tip 0e16d3a98: 5213 passed, 155 skipped, 3 xfailed, GATE_CPU_RC=0. The tip deleted prose tests in compass(tests): delete the tests that assert prose #492, which accounts for 5213 against 5281.

The merged tree's atom/mesh is the head's (7cbd79632), so the head's Rust result covers it. Lib suite, gpu_docker: 1110 passed, rc 0, 53.5 s.

Flake: tree.rs is the same blob at base, tip and head. Alone, the test fails in 28 of 500 runs at the head and 27 of 500 at the tip, every time with "Tenant empty should have positive size". It failed in none of 15 full lib runs at the head (these runs skip the 40 s stub test). The cause, with a deterministic probe, is in #514. test_load_counter_performance (worker.rs, not touched here) failed in 3 of the same 15 runs.

🤖 Generated with Claude Code

- D4 table loses its Sites column; the crosswalk and the count paragraphs go. Each site's mechanism is the `mechanism` field of its row in sync_sites.json (#476). No prose states a site count. - D4, D5 and D9 cite code by path and symbol, not by line; D5's cite-audit bullet is deleted. - D5's K8 table and D9 item 9 state one atomesh bound, the --worker-request-timeout-secs option (#478); the 30 s client default is never reached (#477). The D7 log row takes #448's decision. - D4's zero-lookahead and DP rules keep the decisions and link D3 for the sizing and the critical-path example. - "Mistakes fall on the loud side" is limited to sends and receives; the clock-source lint and validation catch the rest. - D4's TSO handler case drops the rejected-design history. - README: D4 headline row and the doc 01 index row rewritten from the log; the Atomesh and wall-clock Scope rows follow D5; the straggler is checked on receipt; the header states no decision count. - "simulated window" becomes "simulation window", "stall report" becomes "stall diagnostic". Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

…ield Conflicts resolved, keeping both sides: - atom/compass/audit/sync_sites.json: the two router rows #478 rewrote take the tip's file, line, anchor and why, and keep the branch's mechanism K8. - atom/compass/audit/sync_scan.py: the tip deleted category_counts with the count test (#492); the branch's counts_by, which replaced it, goes with it. - tests/compass/test_sync_inventory.py: the tip deleted the stated-count test (#492); the branch's extension of it to mechanism tables goes with it. The crosstab test counts mechanisms with Counter instead of counts_by. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

…stale doc-01 statements (#584) Per the owner's ruling of 2026-10-02, doc 11 and doc 01 now say the metrics push and refresh run on simulated time as daemon timers and the traffic LP scrapes /metrics on simulated time; _last_refresh is stamped with simulated time. Doc 01 adds uvicorn's Server.main_loop tick and keep-alive to the daemon deadlines. The three metrics rows of sync_sites.json keep category "ignore" and their original why; mechanism_why carries the daemon wording (K7). Doc 01 (#577): only DEFAULT_WORKER_HTTP_TIMEOUT_SECS is compiled in (DEFAULT_WORKER_REQUEST_TIMEOUT_SECS is the default of a CLI option, #478), and the deleted test_kv_blob_doc_table.py reference now points to test_kv_blob_site.py. The design README summary of doc 11 is updated to match. CPU gate on node 18 at 9ac55a0: 5811 passed, 155 skipped, 3 xfailed, GATE_CPU_RC=0. The merged tree with b645537 (#558, clock files only) passes the inventory tests. Closes #535. Closes #577. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

jgong5 commented Sep 29, 2026

View reviewed changes

This was referenced Sep 29, 2026

design: doc 01 names a 30 s atomesh bound that bounds no request (found in #469) #477

Open

compass(audit): a mechanism field (K1-K9) on every sync-inventory row, send_multipart in the scanner #476

Merged

jgong5 mentioned this pull request Sep 30, 2026

atomesh: prefix_match records the placeholder tenant "empty" on a tenantless node, flaking test_tree_structure_integrity_after_stress #514

Open

jgong5 marked this pull request as ready for review September 30, 2026 07:04

jgong5 merged commit 91e19c5 into feature/atomcompass_new Sep 30, 2026

jgong5 mentioned this pull request Sep 30, 2026

compass(design): revise the design documents to the PDES time model #443

Open

2 of 39 tasks

jgong5 mentioned this pull request Oct 2, 2026

design: doc 01 describes two Atomesh timeouts as constants and names a deleted test (found in #575) #577

Closed

jgong5 added the module: compass-audit atom/compass/audit/ and its tests label Oct 10, 2026

Navigation Menu

Repository navigation

atomesh: make the fan-out request timeout a CLI option (--worker-request-timeout-secs) - #478

atomesh: make the fan-out request timeout a CLI option (--worker-request-timeout-secs)#478
jgong5 merged 2 commits into
feature/atomcompass_newfrom
compass/issue-469-atomesh-timeouts

jgong5 commented Sep 29, 2026 •

edited

Loading

Uh oh!

jgong5 Sep 29, 2026 •

edited

Loading

Uh oh!

jgong5 Sep 29, 2026 •

edited

Loading

Uh oh!

jgong5 Sep 29, 2026 •

edited

Loading

Uh oh!

jgong5 Sep 29, 2026 •

edited

Loading

Uh oh!

jgong5 commented Sep 29, 2026 •

edited

Loading

Uh oh!

jgong5 commented Sep 30, 2026

Uh oh!

jgong5 commented Sep 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

flag	`parse_from`	`RouterConfig::validate()`	load
`--worker-request-timeout-secs 5`	ok	ok	`7`
`--worker-request-timeout-secs 0`	ok	ok	`-1`

		@@ -2483,27 +2483,27 @@
		"anchor": "pub const DEFAULT_WORKER_HTTP_TIMEOUT_SECS",
		"category": "C1",

Conversation

jgong5 commented Sep 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Dev record

Named result

Gates

Uh oh!

jgong5 Sep 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jgong5 Sep 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jgong5 Sep 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jgong5 Sep 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jgong5 commented Sep 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jgong5 commented Sep 30, 2026

Uh oh!

jgong5 commented Sep 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

jgong5 commented Sep 29, 2026 •

edited

Loading

jgong5 Sep 29, 2026 •

edited

Loading

jgong5 Sep 29, 2026 •

edited

Loading

jgong5 Sep 29, 2026 •

edited

Loading

jgong5 Sep 29, 2026 •

edited

Loading

jgong5 commented Sep 29, 2026 •

edited

Loading