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-4b shipped (server v2.19.0) R4-4b ExecutionService refactor + list fan-out landed via noetl/server#55 -> v2.19.0. In-server migration to DbPoolMap complete (R4-3 + R4-4 + R4-4b). R4-5 (kind validation N=2 shards) is the final R4 round. Sessions-Log + Releases timeline + Umbrella-Rust-Server-Port all updated in lockstep.
log: Phase F R4-4 shipped (server v2.18.0) R4-4 cross-shard fan-out + event_id resolver landed via noetl/server#54 -> v2.18.0. state.db now absent from entire src/ tree; R4-3 + R4-4 complete the handler-side migration. R4-4b (ExecutionService refactor + list fan-out) is the next slice; R4-5 is kind validation N=2. Sessions-Log + Releases timeline + Umbrella-Rust-Server-Port all updated in lockstep.
log: Phase F R4-3c shipped — R4-3 complete (server v2.17.0) R4-3c health.rs cutover landed via noetl/server#53 -> v2.17.0. R4-3 (per-execution handler cutover) complete across events.rs + execute.rs + health.rs. Only 2 state.db sites remain in the whole codebase, both event_id-keyed in events.rs, both TODO(R4-4). Sessions-Log + Releases timeline + Umbrella-Rust-Server-Port all updated in lockstep.
log: Phase F R4-3b shipped (server v2.16.0) R4-3b execute.rs cutover landed via noetl/server#52 -> v2.16.0. Clean 3+3 split: 3 catalog reads -> cluster(), 3 per-execution writes -> pool_for(execution_id). state.db absent from execute.rs. Sessions-Log + Releases timeline + Umbrella-Rust-Server-Port all updated in lockstep.
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 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
wiki: #49 Phase C kind-validated on Rust server; axum 0.8 bug fixed - Umbrella-Rust-Server-Port: Phase C status flipped from "Rust unit-tested, kind-validation deferred" to "kind-validated on both Python AND Rust (same harness, 11/11 PASS)". Endpoint table now shows ✅ kind-validated for the Rust column on all 5 endpoints + the auth gate. - Sessions-Log: new top-of-page entry covering the diagnosis + fix (axum 0.7 → 0.8 route-syntax migration was missed in 18 places), the side-by-side deploy on kind, and the two follow- up findings (NATS auth format + NOETL_ENCRYPTION_KEY default) that were flagged but not blockers. - Releases: new noetl/server v2.1.2 row (pending merge of #14) + ops timeline entry for the kind-deployment manifest #147. - Home: #49 row flipped to "Phase C kind-validated on both Python AND Rust; identical 11/11 pass" with Phase D called out as the next big-lift piece. Ships in lockstep with noetl/server#14 + noetl/ops#147 per Rule 2b and Rule 0a.
wiki: Phase 1.a kind-validated on Python After kind validation of noetl/noetl#659 / #660 (Python v4.10.1) and noetl/server#12 / #13 (Rust v2.1.1): - Sessions-Log adds "2026-06-02 (late evening) — Phase 1.a kind- validated on Python" entry at top. Captures the three real-world bugs found, the validation harness output, and DB-side verification. - Releases page Timeline + per-repo log gain v4.10.1 (Python fix release) and v2.1.1 (Rust fix release) rows. - Umbrella-Rust-Server-Port Phase C status: Python column flips to "kind-validated"; Rust column stays "unit-tested" (kind validation deferred to side-by-side deploy). Three-bug summary added. - Umbrella-System-Pool-Design Phase 1.a same status flip + harness link. - Home dashboard status text updated: - #49: "Phase C ✅ shipped + kind-validated on Python; Rust unit- tested, kind-validation deferred" - #46: "Phase 1.a ✅ kind-validated (Python); Phase 1.b + Phase 2 ready to start" Per agents/rules/wiki-maintenance.md Rule 0a: every session lands its wiki updates in the same change set. This bump satisfies that for the kind validation work. Refs noetl/ai-meta#46 Refs noetl/ai-meta#49
wiki: Phase C complete on both Python + Rust servers After noetl/server#12 merged (mirroring noetl/noetl#659 in Rust): - Sessions-Log adds "2026-06-02 (evening) — Phase C Rust side shipped (both servers complete)" entry at top. Captures the implementation details, the new deps (subtle, serial_test), the test counts, and the phase-status flip. - Releases page Timeline + per-repo log gain the noetl/server@fdf775a row (no version tag yet; awaits semantic-release). - Umbrella-Rust-Server-Port Phase C table — Rust column flips from ⏳ to ✅ for all 6 endpoints + auth gate + tracing spans. - Umbrella-System-Pool-Design Phase 1.a — same flip with the c94075e SHA reference for the server pointer bump. - Home dashboard — both primary umbrellas' status texts updated: - #49: "Phase C ✅ on both Python + Rust; other phases pending" - #46: "Phase 1.a ✅ on both servers; Phase 1.b + Phase 2 pending kind validation" Per agents/rules/wiki-maintenance.md Rule 0a: every session that lands meaningful cross-repo work updates the ai-meta wiki in the same change set. This bump satisfies that for noetl/server#12. Refs noetl/ai-meta#49 Refs noetl/ai-meta#46
wiki: Phase C Python side landed (noetl v4.10.0) After noetl/noetl#659 merged + tagged as v4.10.0: - Sessions-Log gets a new "2026-06-02 (evening) — Phase C Python side shipped" entry at top with the endpoint inventory, the PR link, and the next-session plan. - Releases page Timeline gains the v4.10.0 row + a per-repo entry under "noetl/noetl". - Umbrella-Rust-Server-Port Phase C table flips Python column to ✅ (5 endpoints + auth gate); Rust column stays ⏳ pending the mirror sub-issue. - Umbrella-System-Pool-Design Phase 1.a same flip + ai-meta SHA reference (cdb597d). - Home dashboard active-umbrella table status text updated — #49 shows "Phase C Python ✅; Rust mirror pending"; #46 shows "Phase 1.a Python ✅; Phase 1.b + Phase 2 pending kind validation". Per agents/rules/wiki-maintenance.md Rule 0a: every session that lands meaningful cross-repo work updates the ai-meta wiki in the same change set. This bump satisfies that for #659. Refs noetl/ai-meta#49 Refs noetl/ai-meta#46
add sharding sequence + system playbook execution flow diagrams Continuation of the 2026-06-02 diagram pass: 1. **Sharding sequence diagram** added to Phase F of #49 (Umbrella-Rust-Server-Port.md). Shows: - Initial /api/execute call lands on any shard via the gateway/ingress load balancer. - Subsequent shard-aware calls (eg. GET /api/executions/{id}) route by shard_id = hash(execution_id) % N. - Outbox claim distributes per-shard via system pool worker pod ownership. - Sharding rules table — what's shared (catalog, credentials) vs what's sharded (execution, event, command, outbox). - Migration path: N=1 first, then scale to N=3. 2. **System playbook execution flow** added to Phase 2 of #46 (Umbrella-System-Pool-Design.md, under system/outbox_publisher). Shows: - KEDA HTTP scaler triggers off pending-count endpoint. - System pool worker claims command from NATS. - Playbook executes 4 steps: claim_batch (HTTP) → publish_batch (NATS iterator) → mark_published (HTTP) → mark_failed (per-row failure branch). - Worker emits call.done → outbox → next iteration picks it up (bootstrap-tolerant cycle closure). - Auth gate noted (system-pool-sa-token on /api/internal/*). Together with the previously-added interlock + Python-trajectory + data-access-boundary diagrams, the dashboard now answers: - What's deployed today - How the two primary umbrellas connect - Where we're heading (Python footprint trajectory) - Why workers can't touch DB directly - How sharding will work - How a system playbook actually runs All from wiki pages a developer can scan in a few minutes.
add architectural diagrams across dashboard pages After session 2026-06-02 (late afternoon) request: "add that diagrams too" — make the architecture readable at a glance from any wiki page a developer might land on. Four diagrams added: 1. **Two-umbrella interlock** (#49 + #46) — visual of how the Rust server port's Phase C unblocks the system pool's Phase 2. Same API surface produced by one, consumed by the other. Added to: - Home.md (architecture-at-a-glance section) - Umbrella-Rust-Server-Port.md - Umbrella-System-Pool-Design.md 2. **Long-term Python trajectory** — three-column view: today / after #46 Phase 2 / long-term. Shows Python becoming a container payload, not a platform runtime. Added to: - Home.md - Umbrella-System-Pool-Design.md 3. **Data access boundary** — workers + system worker pool call server HTTP API; only the server talks to Postgres directly; external-subsystem playbooks (auth) go direct to external systems. Added to: - Data-Access-Boundary.md (convention page) 4. **Today's deploy topology** (pre-existing, kept) — gateway → server → outbox/projector + NATS → worker pools. Already on Home.md. Together these give a developer landing on Home immediately: - What's deployed today - The two primary in-flight umbrellas + how they interlock - The Python footprint trajectory Each Umbrella-* page carries its relevant subset so a developer opening a specific umbrella also gets the visual context. Issue comments mirror these diagrams: - #49 — interlock diagram (gh issue comment 4605222980) - #46 — interlock + trajectory diagrams (gh issue comment 4605227009)
prioritize Rust server port — add #49 umbrella page + dashboard promotion User directive 2026-06-02 late afternoon: "prioritize server rust port, taking into account latest architectural decisions." Filed noetl/ai-meta#49 — Rust server FastAPI parity port — with six-phase plan that bakes in the day's architectural decisions (data access boundary, system pool interlock, sharding-first, strangler-fig cutover, kind-validation per endpoint). Dashboard changes: - New page Umbrella-Rust-Server-Port.md — full phasing + constraints from current rule set + first-three-sub-issues plan + recent-activity table. - Home.md — Active-umbrella table reorganised; two PRIMARY umbrellas (#49 + #46) at the top with the interlock callout; #43, #47, #48 in their own swim lanes. Total active = 5. - _Sidebar.md — Active Umbrellas section promotes #49 + #46; closed umbrellas (#30, #45) moved to a new "Closed Umbrellas (2026-06-02)" subsection. - Sessions-Log.md — adds "2026-06-02 (late afternoon) — Rust server port prioritised" entry at top with the next-session plan (Phase C sub-issue, parity diff harness, EE-4 crate). The two PRIMARY umbrellas interlock: Phase C of #49 (server internal endpoints) UNBLOCKS Phase 2 of #46 (system playbooks). Next session opens Phase C sub-issue on noetl/server FIRST.