We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
There was an error while loading. Please reload this page.
log: Phase F R4-3a shipped (server v2.15.0) + Phase G design recorded R4-3a events.rs cutover landed via noetl/server#51 -> v2.15.0. 9 per-execution sites moved to pool_for(execution_id); 1 cluster-wide catalog read to cluster(); 2 event_id-keyed sites deferred to R4-4. Also records the mid-round design pivot: user raised whether shard endpoints should be DB-resident keychain-backed records. Decision: deferred to Phase G; full design captured on noetl/server wiki sharding-design § Phase G (1631644).
log: Phase F R4-2 shipped (server v2.14.0) R4-2 AppState wiring landed via noetl/server#50. DbPoolMap is now an AppState field; handler call-sites untouched. R4-3 (next round) does the per-execution cutover (~12 files). Sessions-Log + Releases timeline + Umbrella-Rust-Server-Port all updated in lockstep.
log: Phase F R4-1 shipped (server v2.13.0) R4-1 pool layer landed via noetl/server#49. Sessions-Log + Releases timeline + Umbrella-Rust-Server-Port "Recent activity" all get the R4-1 entry. Per-shard physical Postgres decision recorded; `ShardingConfig` + `DbPoolMap` ship dormant (NOETL_SHARDS empty → single-pool fallback bit-identical to today). Next: R4-2 (AppState wiring).
log: Phase F R3b-3 shipped (noetl/ops#158) Sessions-Log + Releases timeline + Umbrella-Rust-Server-Port "Recent activity" all get the R3b-3 entry. Closes out the R3b drift-guard sequence: R3b-1 (server v2.12.0) + R3b-2 (gateway v3.2.0) + R3b-3 (ops `validate-shard-drift-guard.sh`) Next round: Phase F R4 (DB sharding) or R5 (cutover).
wiki: Phase F R3b-2 shipped (gateway v3.2.0) — shard-info twin endpoint Sessions-Log entry + Releases v3.2.0 row. Diagnostic endpoint pair now fully assembled (server R3b-1 + gateway R3b-2); R3b-3 (integration test in noetl/ops) closes the drift-guard. Refs noetl/ai-meta#49 Refs noetl/gateway#26
wiki: Phase F R3b-1 shipped (server v2.12.0) — shard-info diagnostic endpoint Sessions-Log entry + Releases v2.12.0 row. First slice of R3b (end-to-end drift-guard). Adds the server side of the diagnostic endpoint pair; R3b-2 adds the gateway twin; R3b-3 wires the integration test in noetl/ops. Refs noetl/ai-meta#49 Refs noetl/server#47
wiki: Phase F R3a-2 shipped (gateway v3.1.0) — body-param routing Sessions-Log entry captures the R3a-2 deliverable + the commit-body discipline win (semantic-release correctly minor-bumped this time because we avoided the literal BREAKING CHANGE token). Releases row for gateway v3.1.0 covers the full R3a-2 scope + the no-regression-from-R3a property. Refs noetl/ai-meta#49 Refs noetl/gateway#24
wiki: note gateway Cargo.toml fix landed (Phase F R3a follow-up)
wiki: Phase F R3a shipped (gateway v3.0.0) + semantic-release parser quirk Sessions-Log entry captures the R3a deliverable + the semantic-release misparse that bumped v2.14.1 → v3.0.0 (the phrase "no breaking change to wire shape" triggered the BREAKING CHANGES heuristic). Lesson recorded: future commit bodies should avoid the literal "BREAKING CHANGE" / "breaking change" token, even with a negation. Releases row for gateway v3.0.0 with the full R3a scope + the note on the version bump quirk. Refs noetl/ai-meta#49 Refs noetl/gateway#21
wiki: Phase F R2 shipped — server v2.11.0 (sharding helper) Sessions-Log entry captures the R2 deliverable + the hash function decision matrix (twox-hash XxHash64 with fixed seed 0; alternatives rejected for stability / distribution / dep-weight reasons). Releases row for v2.11.0 covers the full migration scope. Refs noetl/ai-meta#49 Refs noetl/server#45
wiki: Phase F R1.5 kind-validation pass — machine_id=1 propagates end-to-end Built noetl-server-rust v2.10.1 image, loaded into kind, applied the manifest with NOETL_SERVER_MACHINE_ID=\"1\" from ops#156. Validation: ✅ startup log shows source=\"NOETL_SERVER_MACHINE_ID\"; execution_id 320816801799737344 minted by /api/execute carries machine_id bits = 1 (matches manifest); all 3 events (playbook_started, command.issued, command.claimed) on the test execution share the same machine_id portion. Sessions-Log entry covers the full validation procedure + records the snowflake structure decoded from the test event_id. Closes the kind-validation follow-up from R1.5. Phase F R1.5 is fully shipped now (code v2.10.1 + manifest ops main + validation pass). Refs noetl/ai-meta#49
wiki: Phase F R1.5 follow-on — Rule 2a drift catch + env-var rename + ops manifest Two coordinated PRs landed: - noetl/server#43 (v2.10.1): rename config field machine_id → server_machine_id so envy reads NOETL_SERVER_MACHINE_ID (matching the deployment-spec page that documented it that way). Caught by the new wiki-maintenance.md Rule 2a discipline during the ops manifest prep — the deployment-spec page was treated as single source of truth and the mismatch surfaced. - noetl/ops#156: adds NOETL_SERVER_MACHINE_ID to the noetl-server-rust Deployment (value="1" for the current single-replica setup; multi-replica derivation patterns documented inline). The drift would have shipped silently otherwise: server would have fallen back to HOSTNAME-derived FNV-1a hashing in production, with collision risk at multi-replica scale. Rule 2a did its job. Sessions-Log entry + Releases v2.10.1 row. Refs noetl/ai-meta#49 Refs noetl/server#43 Refs noetl/ops#156
wiki: Phase F R1.5 done (server v2.10.0) + deployment-spec pages Sessions-Log entry captures the R1.5 snowflake migration on noetl-server AND the new deployment-specification pages on both the noetl/server and noetl/worker wikis. Going forward these pages are the single source of truth for env vars + ports + dependencies; any code change that touches std::env::var or envy::from_env must update them in the same change set per the new agents/rules/wiki-maintenance.md Rule 2a. Releases.md row for server v2.10.0 with the full migration scope + companion wiki update + manifest follow-up call-out. Refs noetl/ai-meta#49 Refs noetl/server#42
wiki: Phase F R1 done — sharding design on noetl/server wiki Umbrella `Forward` section: R1 marked shipped via noetl/server#40 + noetl/server wiki `sharding-design` page. R1.5 (app-side snowflake ID migration) flagged as the next concrete sub-issue — load-bearing for R4 (DB sharding) per observability.md Principle 3. Sessions-Log entry captures the three design decisions made in R1 (full-i64 modulo, gateway-aware routing, single-master cluster- wide tables) + the one open question deferred to R4 (DB partition scheme: Citus vs per-shard schemas vs per-shard DBs). Refs noetl/ai-meta#49
wiki: Phase F sharding survey + EE-4 catch-up Sessions-Log entry Umbrella-Rust-Server-Port gains a new "Phase F — sharding survey (2026-06-05)" section capturing the read-only investigation findings: - Natural shard boundary is the execution. All per-execution state (event log, command queue, execution records, outbox, variables) lives on one shard; cluster-wide state (catalog, credentials, keychain, runtime registration) replicates across shards or sits behind a shared read-only path. - 40+ endpoint inventory tagged shardable vs cluster-wide. - 5 shardable DB tables, 4 cluster-wide. - Three open design questions with lean recommendations: - Gateway-aware vs server-aware routing → gateway-aware for F, server-aware as a follow-up if it becomes a bottleneck. - Modulo on full snowflake vs timestamp/machine_id → full i64 (timestamp creates time-based hotspots; machine_id clusters). - Catalog/credential sync strategy → single-master for F, revisit per-shard read replicas if replication lag bites. - Phase D-shape 5-round decomposition: R1 design doc; R2 server- side shard_id(); R3 gateway-side dispatch; R4 DB sharding; R5 cutover. - Load-bearing prerequisite: app-side snowflake IDs (per observability.md Principle 3) want to land before R4 — otherwise the DB-side noetl.snowflake_id() function either becomes per- shard (clusters within a shard) or needs global sync (defeats the point). Sessions-Log: new entry covering both the per-repo issue/wiki catch-up earlier in the session AND the Phase F survey landed just now. Refs noetl/ai-meta#49
wiki: EE-4 PR 3 — noetl-server adopts noetl-events, EE-4 sequence fully shipped (server v2.9.0) Sessions-Log: new entry for the night session that triggered the cli release workflow + opened + landed PR 3. Three crates published to crates.io (noetl-events 0.1.0 first release, noetl-executor 0.4.0, noetl 4.9.0), server takes noetl-events as a direct dep, the wire- compat semantic is now anchored to the canonical envelope. Umbrella-Rust-Server-Port: Next concrete steps refreshed — EE-4 sequence fully shipped (all three rounds + the crates.io publish). Forward is now Phase F (sharding) + the remaining-Python-only- endpoints scope from Phase A's parity harness. Releases.md: added a row for the cli crates.io publish bundle (noetl-events 0.1.0 + noetl-executor 0.4.0 + noetl 4.9.0) and a row for noetl/server v2.9.0 (EE-4 PR 3). Last-refreshed bumped to 2026-06-05. Refs noetl/ai-meta#49 Refs noetl/server#38 Refs noetl/cli#50
wiki: EE-4 PR 2 merged — crates.io publish prep for noetl-events 0.1.0 + executor 0.4.0 Sessions-Log entry for noetl/cli#50. Umbrella Next concrete steps now notes the publish is pending the next release workflow run + flags the pre-existing gcs_upload bin-verification failure that PR 2's 0.4.0 re-publish should fix as a side effect. EE-4 PR 3 on noetl/server is blocked until noetl-events 0.1.0 actually lands on crates.io. Refs noetl/ai-meta#49 Refs noetl/cli#50
wiki: EE-4 PR 1 — noetl-events workspace crate extracted Sessions-Log entry covering noetl/cli#49 (EE-4 PR 1). Umbrella Next concrete steps now leads with EE-4 PR 2 (crates.io publish) + EE-4 PR 3 (server adoption). The cli bin bumped to v4.9.0 via release-please on top of the merge; no tag yet so Releases.md gets no row this round. Refs noetl/ai-meta#49 Refs noetl/cli#49
wiki: Phase D R3 e2e fully closes — server v2.8.3 + R3b iterators drain Sessions-Log entry covering noetl/server#37 (Phase D R3b end-to-end). Umbrella gains Phase D status table marking all 4 rounds e2e-validated; Next concrete steps now leads with EE-4 envelope crate. Releases.md gains v2.8.3 row. End-to-end kind validation, all 4 fixtures + R3b: - R2 2-step linear: playbook.completed - R3a conditional both branches: playbook.completed - R3b iterator (3 iterations): playbook.completed - R3c parallel: playbook.completed Phase D engine port is materially feature-complete with full e2e validation on kind. Refs noetl/ai-meta#49 Refs noetl/server#37
wiki: #53 closes + Phase D R3 e2e drained — server v2.8.1/v2.8.2 + worker v5.11.0 Sessions-Log entry covering all three PRs (server #35, worker #41, server #36) + the diagnosis chain that surfaced each. Releases.md gains rows for v2.8.1 (Gap 2), v5.11.0 (Gap 1), v2.8.2 (R3a skip-chain re-entry guard). Umbrella Recent activity gains the midday entry; Next concrete steps now leads with R3b-2 (worker iter-injection). End-to-end kind validation: - R2 2-step linear: ✓ playbook.completed - R3a conditional both branches: ✓ playbook.completed - R3c parallel: ✓ playbook.completed - R3b iterator: still gated on R3b-2 (worker-side Python iter-variable injection) Refs noetl/ai-meta#49 Refs noetl/ai-meta#53
wiki: #53 — root-cause of Rust worker → Rust server e2e gap (replaces dual-worker race note) Diagnosed during R3c re-validation: dual-worker NATS race was a cosmetic symptom. Root cause is the Rust worker's NOETL_SERVER_URL points at the Python server, so its emitted events flow back to Python (recorded to shared DB, but no Rust trigger_orchestrator invocation). Pointing the worker at the Rust server surfaces a second gap — /api/worker/pool/register rejects the worker's payload shape. Filed noetl/ai-meta#53 with both fix options + acceptance criteria. Refs noetl/ai-meta#49 Refs noetl/ai-meta#53
wiki: #49 Phase D R3c — parallel branches (server v2.8.0); Phase D R3 closes Sessions-Log entry covering noetl/server#34. Releases.md row for v2.8.0. Umbrella Recent activity gains the R3c row, Phase D status table marks R3 closed, Next concrete steps now lead with dual-worker NATS subject race (blocks e2e on R3b + R3c) and R3b-2 worker iter-injection. Refs noetl/ai-meta#49 Refs noetl/server#34
wiki: #49 Phase D R3b — iterator fan-out + state aggregation (server v2.7.0) Sessions-Log entry covering noetl/server#33 + Releases.md row for v2.7.0. Umbrella Recent activity gains the R3b row and Next concrete steps refreshed to lead with R3b-2 (worker iter injection) + R3b-3 (orchestrator re-trigger investigation) follow-ups before R3c parallel. Refs noetl/ai-meta#49 Refs noetl/server#33
wiki: #49 Phase D R3a — step.when enable guard (server v2.5.0/v2.6.0) Sessions-Log entry covering noetl/server#32 (Phase D R3a) + adds the v2.5.0 (Phase D R2 retro) and v2.6.0 (Phase D R3a) rows to Releases.md. Umbrella-Rust-Server-Port Recent activity gains the R3a row and Next concrete steps refreshed to R3b iterators / R3c parallel / NATS race / EE-4 / Phase F. Refs noetl/ai-meta#49 Refs noetl/server#32
wiki(sessions): #49 Phase D R2 — orchestrator wired into event ingest Sessions-Log entry + Umbrella-Rust-Server-Port update for noetl/server#31 landing. Phase D checklist flipped to materially complete; Next concrete steps refreshed to Phase D R3 + dual-worker NATS race follow-up + EE-4 + Phase F. Refs noetl/ai-meta#49 Refs noetl/server#31
docs(releases): noetl/server v2.4.3 — Phase B closed - Releases.md: timeline row + per-repo noetl/server v2.4.3 entry documenting the build_result_object refactor + Phase B closure. - Sessions-Log.md: 2026-06-04 late-morning entry — Phase B done, all four rounds genuinely green, today's 12-release Rust server progression captured. Refs noetl/ai-meta#49, noetl/server#21, noetl/server#29
docs(releases): noetl/ops cd2182f — Phase B R4 load-smoke harness - Releases.md: timeline row for the Round 4 harness + baseline numbers + the noetl/server#29 finding flushed during the run. - Sessions-Log.md: 2026-06-04 mid-morning entry — all 4 rounds shipped structurally; #29 needs to land before pure-Rust path is truly green; #21 stays open until then. Refs noetl/ai-meta#49, noetl/server#21, noetl/server#29
docs(releases): noetl/server v2.4.2 — Phase B R3 args:{} fix - Releases.md: timeline row + per-repo noetl/server v2.4.2 entry documenting the args:null → args:{} fix. - Sessions-Log.md: 2026-06-04 early-morning entry covering the triage + the now-clean Round-3 lifecycle. Round 4 (load smoke) unblocked with status=ok dominating. Refs noetl/ai-meta#49, noetl/server#21, noetl/server#27
docs(releases): noetl/server v2.4.1 + ops ec492dd — closes noetl/server#26 - Releases.md: timeline rows for v2.4.1 + ops ec492dd; per-repo noetl/server v2.4.1 entry covering the NATS publish, NATS auth fix, and noetl.command insert. - Sessions-Log.md: 2026-06-03 late-evening entry covering the three findings flushed in one PR + Phase B sub-issue Round 3 now ✅, Round 4 unblocked. Refs noetl/ai-meta#49, noetl/server#21, noetl/server#26
docs(releases): noetl/ops e1832b3 — Phase B R3 harness + noetl/server#26 finding - Releases.md: timeline row for the Round 3 validation script (noetl/ops#153) + note that it surfaced noetl/server#26 on first run. - Sessions-Log.md: 2026-06-03 evening entry covering the harness + finding + the blocked-on noetl/server#26 status. Refs noetl/ai-meta#49, noetl/server#21, noetl/server#26