185 Commits

Author	SHA1	Message	Date
hongming	878c74eafe	Merge pull request #1785 from chore/remove-unmaintained-runtimes ... chore: retire unmaintained workspace runtimes	2026-05-24 07:23:48 +00:00
claude-ceo-assistant	f7e2976324	chore: retire unmaintained workspace runtimes	2026-05-23 23:45:09 -07:00
hongming	f1571a04ab	test(e2e): guard staging orphan cleanup coverage	2026-05-23 23:16:38 -07:00
agent-dev-a	7f0f33739b	fix(e2e): #1644 Part A — peer-visibility scripts consume inline auth_token (#1680) ... Co-authored-by: agent-dev-a <agent-dev-a@agents.moleculesai.app> Co-committed-by: agent-dev-a <agent-dev-a@agents.moleculesai.app>	2026-05-23 19:51:59 +00:00
cp-be	6c7f66fa31	feat(workspace-server): kill DefaultModel + require model at Create (CTO 2026-05-22 SSOT) (#1667) ... Co-authored-by: Molecule AI · cp-be <cp-be@agents.moleculesai.app> Co-committed-by: Molecule AI · cp-be <cp-be@agents.moleculesai.app>	2026-05-23 10:15:18 +00:00
Molecule AI Dev Engineer A (Kimi)	231fb5ddab	fix(e2e): #1646 — raise staging SaaS provisioning timeout (flaky tenant-provisioning latency, not a code regression) ... - Make workspace-online timeout env-configurable (E2E_WORKSPACE_ONLINE_TIMEOUT_SECS) and raise default from 1800s (30 min) to 3600s (60 min). - Update wait_workspaces_online_routable() to consume the variable instead of a hardcoded 1800s, and report the actual timeout in the failure message. - Update step-7/11 call-site label and inline comment to reference the configurable timeout. This is a MITIGATION for flaky tenant-provisioning latency observed in #1646 comment 43710: the staging SaaS smoke canary alternates pass/fail on identical SHAs (e.g. run 92819 success / 92706 fail / 92667 success). The real cause is variable EC2+cold-boot latency, not a code regression. Raising the deadline gives flaky-but-eventually-successful provisioning room to complete without causing false canary failures. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-22 17:17:02 +00:00
core-fe	3112f394eb	fix(ci): path-scope main push heavy checks	2026-05-21 23:51:16 -07:00
core-fe	805486e36e	fix(e2e): wait after config save restarts workspace	2026-05-21 23:20:24 -07:00
core-fe	8c3234e4d2	fix(e2e): retry delegation A2A cold starts	2026-05-21 22:48:55 -07:00
core-fe	3a82e1f1b1	fix(e2e): use stable MiniMax model default	2026-05-21 22:34:42 -07:00
core-fe	0253cdeb47	fix(e2e): retry native-session busy A2A	2026-05-21 22:00:31 -07:00
core-fe	6f98ac062e	fix(e2e): wait for routable workspace before A2A	2026-05-21 21:31:58 -07:00
core-fe	086b479dca	Clarify EIC diagnose SG guidance	2026-05-21 19:38:29 -07:00
core-fe	3e28bf5943	Fail E2E teardown on leaked EC2	2026-05-21 17:13:42 -07:00
core-devops	119743d0de	test(e2e): forbid dev token path in staging peer visibility	2026-05-21 13:21:45 -07:00
core-devops	eb21a02b6d	test(e2e): support empty auth headers on mac bash	2026-05-21 12:41:04 -07:00
core-fe	4f85ef5209	test(e2e): expose peer visibility token fallback failures	2026-05-21 10:17:23 -07:00
core-fe	8fc27f4d69	ci: compensate cancelled push status noise	2026-05-21 00:19:56 -07:00
hongming	704a8ab7de	Merge pull request #1634 ... ci: path-scope required CI lanes on PRs	2026-05-21 06:59:25 +00:00
core-fe	e358b9b92f	ci: fix PR path filter base diff	2026-05-20 23:12:27 -07:00
core-devops	7f59b7fd35	fix(watchdog): add HEAD-recheck + settling delay to suppress cancel-cascade false-positives (#1635)	2026-05-21 06:08:40 +00:00
core-fe	c37caa2ec9	ci: share path filter helper	2026-05-20 22:32:17 -07:00
core-fe	6e77083b84	ci: path-scope shellcheck on prs	2026-05-20 22:20:02 -07:00
core-fe	3a3f670662	ci: path-scope canvas on prs	2026-05-20 22:17:30 -07:00
core-devops	07457ad556	fix(core): add admin workspace token mint route	2026-05-20 22:02:54 -07:00
core-fe	30a8aa10b8	ci: path-scope platform go on prs	2026-05-20 22:02:54 -07:00
core-devops	022cc1136b	fix(core): mint staging peer visibility token fallback	2026-05-20 21:35:42 -07:00
hongming	a1cfd085a8	Merge pull request 'chore(runtime): delete core workspace copy' (#1620) from chore/delete-core-workspace-runtime into main	2026-05-21 04:23:33 +00:00
core-fe	16b203fff1	ci: keep browser e2e out of normal pr path	2026-05-20 21:02:33 -07:00
core-devops	1e850af6de	fix(core): use safe urls in api e2e discovery	2026-05-20 20:09:53 -07:00
core-devops	256eeedc69	fix(core): make api e2e use external workspace auth	2026-05-20 19:56:47 -07:00
core-devops	a501d33f80	fix(core): ignore codex placeholder in coverage e2e	2026-05-20 17:44:58 -07:00
core-devops	0aff9cf85f	fix(core): use per-workspace auth in today coverage e2e	2026-05-20 17:24:43 -07:00
core-devops	f088e0ee90	fix(core): decouple local peer visibility from container boot	2026-05-20 16:56:04 -07:00
core-devops	ea4681299d	fix(core): choose keyed parent for local peer visibility	2026-05-20 16:29:13 -07:00
core-devops	b343995c05	fix(core): exercise external connection e2e with external runtime	2026-05-20 15:58:31 -07:00
core-devops	4be7966654	fix(core): satisfy shellcheck for e2e auth patch	2026-05-20 15:24:15 -07:00
core-devops	4c290f49f2	fix(core): make e2e auth explicit after token bootstrap	2026-05-20 15:20:31 -07:00
core-devops	f13a675408	fix(core): use runtime package in e2e after workspace deletion	2026-05-20 15:03:38 -07:00
core-devops	9aa4764301	chore(runtime): delete core workspace copy	2026-05-20 14:47:55 -07:00
infra-runtime-be	5c989fef2f	feat(uploads): bump cap to 100MB + correct-reason error messages ... CTO 2026-05-19 directive on forensic a99ab0a1 (reno-stars >50MB upload that surfaced "signal timed out" when the real cause was file-size + a fixed 60s client timeout): "if its file size issue, should have error that instead saying timeout which is wrong" Bundles the cap raise + the wrong-reason fix in ONE PR because the two are coupled — bumping the server alone would still leak the fixed-60s timeout for legitimate slow uploads; fixing the client alone would 413 every >50MB attempt. Server (push-mode, EC2 workspace): - workspace-server/internal/handlers/chat_files.go: chatUploadMaxBytes 50→100 MB httpClient.Timeout 120→1200 s (matches the new slow-uplink budget) - workspace/internal_chat_uploads.py: CHAT_UPLOAD_MAX_BYTES 50→100 MB CHAT_UPLOAD_MAX_FILE_BYTES 25→100 MB (aligned with total so a single legitimate large file succeeds end-to-end) Canvas: - canvas/src/components/tabs/chat/uploads.ts: MAX_UPLOAD_BYTES 100 MB constant + FileTooLargeError class pre-flight gate: file-size violation throws BEFORE any fetch, with the actionable "File too large (got X MB) — limit is 100MB" computeUploadTimeoutMs: 60s floor + 100 KB/s scaled deadline (was a fixed 60s — the root cause of the forensic) - canvas/src/components/tabs/chat/hooks/useChatSend.ts: mapUploadErrorToReason: routes each cause to ITS OWN message (FileTooLargeError | TimeoutError | server-Error | fallback) no conflation between file-size and connection-too-slow Tests: - workspace-server chat_files_test.go: pins 100 MB constant, asserts sub-cap forwards + over-cap non-2xx - canvas uploads.cap.test.ts (10 cases): pre-flight gate, exact-cap edge, scaled-timeout curve, server-413 propagation, AbortSignal shape — explicit negative on "TimeoutError ≠ FileTooLargeError" - canvas useChatSend.errorReason.test.ts (5 cases): per-cause message contract, explicit negatives that guard against the wrong-reason conflation Test harness mirror: - tests/harness/cf-proxy/nginx.conf: client_max_body_size 50m→100m (this is the harness mirror; the production CF / nginx tier is out-of-repo. If prod still caps at 50m, this mirror passes while prod 413s — surface to ops.) Follow-up (SSOT, NOT in this PR): The 100 MB constant now lives in THREE mirror sites (canvas TS + workspace Python + platform Go). Per feedback_no_single_source_of_truth, the proper fix is exposing the cap via GET /uploads/limits so the client fetches the live value. Filing as a separate issue. References: - task #295 (internal tracker; CTO-authorized this work) - forensic a99ab0a1 (reno-stars 2026-05-19) - feedback_surface_actionable_failure_reason_to_user (CTO 2026-05-17) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-19 20:23:04 -07:00
core-devops	fcf08647c5	fix(ci): main-red-watchdog skips cancel-cascade entries — closes #1564 ... Gitea maps BOTH `action_run.status=2` (Failure) AND `status=3` (Cancelled) to commit-status string `"failure"`. On a busy `main` with `concurrency: cancel-in-progress: true`, every merge burst cancels prior in-flight runs (status=3) — those bubble to the combined-status `failure` rollup and inflate the watchdog's red%, generating phantom `[main-red]` issues (mc#1562/#1552/#1540/#1532/#1527/#1526/#1522/#1503/#1487/#1484). Per mc#1564 the cleanest filter at this layer is option B (description string): cancelled-run entries carry description `"Has been cancelled"`, real failures carry `"Failing after Ns"`. is_red() now excludes the former from the failed[] list, and combined=failure alone (no per-entry detail) only trips red when statuses[] is empty (the CI-emitter-direct edge case from render_body's existing fallback). Match is description == "Has been cancelled" exactly (after strip), not substring, so a hypothetical real-failure log line containing that phrase still counts as red. Canonical Gitea 1.22.6 enum per `models/actions/status.go`: 1=Success, 2=Failure, 3=Cancelled, 4=Skipped, 5=Waiting, 6=Running, 7=Blocked (reference: operator memory reference_gitea_action_status_enum_corrected_2026_05_19 + reference_chronic_red_sweep_cancelled_vs_failed_filter) Tests (6 new, all 36 in suite pass locally): - cancel-cascade entry alone → not red - real-failure entry alone → red (no over-filter) - mixed cancel + real → red, failed[] contains only real failures - all entries cancelled → not red (the phantom-issue case) - combined=failure + empty statuses[] → still red (preserve fallback) - exact-match contract (substring would over-match) Refs: - mc#1564 - mc#1529 (chronic-red triage that surfaced this) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-19 12:12:59 -07:00
claude-ceo-assistant	00351b4551	fix(ci): repair docker-host guardrail follow-up	2026-05-18 19:50:13 -07:00
hongming	685f6d19f4	Merge pull request 'test(e2e): fix-specific coverage for today's merged PRs (mc#1525/1535/1536/1539/1542)' (#1557) from test/e2e-todays-pr-coverage into main	2026-05-19 01:57:33 +00:00
core-qa	ab8ff865e4	test(e2e): add fix-specific E2E coverage for today's merged PRs (mc#1525/1535/1536/1539/1542) ... Per E2E coverage audit 2026-05-18: today's merged platform PRs landed with unit-test coverage only. This adds one consolidated bash E2E (tests/e2e/test_today_pr_coverage_e2e.sh) that exercises each fix through the real HTTP / activity-log path with no mocks of the unit-under-fix, and wires it into the existing e2e-api.yml lane after the poll-mode chat-upload step. What the test asserts: - Section A (mc#1535 + mc#1536): provisions two workspaces back-to-back, pulls /workspaces/:id/external/connection, regex-extracts the `claude mcp add <NAME>` server slug from each install snippet, and asserts (1) both start with `molecule-` (per-workspace, not literal `molecule`) and (2) the two slugs DIFFER (no overwrite class). Codex TOML table key uniqueness is checked too when the codex tab is in the build. - Section B (mc#1525 + mc#1542): probes /admin/workspaces/:id/debug for the presence of GIT_HTTP_USERNAME and GIT_ASKPASS keys in workspace_secrets — pre-#1542 the GIT_HTTP_* key was absent entirely; pre-#1525 there was no env-only askpass wiring. Value-emptiness is tolerated on the dev platform where no persona is seeded (presence is the post-fix regression contract). - Section C (mc#1539): self-delegates via POST /workspaces/:id/delegate with target=self and asserts (a) the API gate returns structured rejection OR (b) no activity_logs rows with source_id=our_uuid AND method != 'delegate_result' surface — the inbox-poller predicate the fix added. Polls activity for 2s, counts violating rows, fails closed on > 0. Why E2E (not just unit): - mc#1525 + mc#1542 ship a unit test that only checks the loader; the REAL contract is "git ls-remote rc=0 inside the container with the env the provisioner builds". This test probes the produced workspace_secrets map at the platform end — one step short of in- container exec, which the e2e-api lane lacks docker-exec privilege for, but materially closer than the loader-only unit. - mc#1535 + mc#1536 unit-tested the slug helper in isolation; the bug was that the SNIPPET STRINGS shipped to the user still had hardcoded `molecule` in the codex/openclaw/hermes branches. The E2E pulls the literal user-facing strings. - mc#1539 unit-tested the inbox _is_self_echo predicate; the E2E hits the actual /delegate → activity-log → poll path. Test pattern follows tests/e2e/test_activity_e2e.sh (set -uo pipefail, check/check_not helpers, BASE default, cleanup at end). EXIT cleanup deletes both provisioned workspaces. Time-bound: 60s default, override via E2E_TIMEOUT. CI-runnable on the existing e2e-api lane (postgres + redis + workspace-server already provisioned earlier in the same job). Refs: PR audit memo 2026-05-18; pairs with feedback_verify_actual_endstate_not_ack_follow_sop (presence-of-end- state-not-ack rule). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-18 18:30:33 -07:00
core-qa	84cba60ec2	test(e2e): add LOCAL backend for the peer-visibility MCP gate ... PR #1298 added the peer-visibility gate but staging-only. Per the standing rule that the local prod-mimic stack must run a MANDATORY local-Postgres E2E BEFORE staging E2E (feedback_local_must_mimic_ production, feedback_mandatory_local_e2e_before_ship, feedback_local_ test_before_staging_e2e), peer-visibility must also run locally so regressions are caught fast/cheap instead of late on cold EC2. - Factor the byte-identical assertion core out of test_peer_visibility_mcp_staging.sh into tests/e2e/lib/ peer_visibility_assert.sh::pv_assert_runtime. It drives the literal JSON-RPC tools/call name=list_peers envelope to POST /workspaces/:id/ mcp via each workspace's OWN bearer through the real WorkspaceAuth + MCPRateLimiter chain, with the same anti-proxy / anti-native-fallback guarantees. NOT a proxy: no registry row, /health, heartbeat, or GET /registry/:id/peers. Only provisioning differs per backend. - Refactor the staging script to source the shared lib (assertion byte-identical; provisioning/teardown/exit-codes unchanged). - Add tests/e2e/test_peer_visibility_mcp_local.sh: local docker-compose backend — POST /workspaces directly, e2e_mint_test_token for the MCP bearer (same model test_priority_runtimes_e2e.sh / test_api.sh use, no new credential flow), wait online, run the shared assertion, scoped per-workspace teardown only (feedback_cleanup_after_each_test, feedback_never_run_cluster_cleanup_tests_on_live_platform). bash-3.2- safe (no associative arrays) so it runs on local macOS dev boxes too. - Wire a peer-visibility-local job into e2e-peer-visibility.yml, bootstrapped exactly like e2e-api.yml's proven E2E API Smoke Test (per-run container names + ephemeral ports, go build, background platform-server). Runs on PR + push (local boot is minutes, not the 30+ min cold-EC2 path), so peer-visibility is part of the local gate that fires before the staging E2E. Its OWN non-required status context `E2E Peer Visibility (local)` — non-required-by-design like the staging job, HONEST gate with NO continue-on-error mask (feedback_fix_root_not_symptom); flip-to-required tracked at #1296 via the bp-required: pending directive. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-18 17:50:01 -07:00
core-devops	2e8603f940	test(e2e): gate fresh-provision peer-visibility via the literal MCP list_peers call ... Hermes and OpenClaw were reported "fleet-verified / cascade-complete" off proxy signals (registry registration + heartbeat; model round-trip 200) while a freshly-provisioned workspace asked "can you see your peers" on canvas actually FAILS (Hermes: 401 on the molecule MCP list_peers call; OpenClaw: native sessions_list fallback, no platform peers). Tasks #142/#159 were even marked "completed" under this proxy-verification flaw. This adds a dedicated staging-E2E gate that codifies the LITERAL user-facing path so it can never silently regress: - New e2e-peer-visibility.yml + tests/e2e/test_peer_visibility_mcp_staging.sh. - Provisions a brand-new throwaway org via the real CP provisioning path + one sibling workspace per runtime under test (hermes, openclaw, claude-code) under a shared parent. - For each runtime, drives the byte-for-byte JSON-RPC tools/call name=list_peers envelope to POST /workspaces/:id/mcp using that workspace's OWN bearer token, through the real WorkspaceAuth + MCPRateLimiter chain. NOT a proxy: not GET /registry/:id/peers, not /health, not the heartbeat table. - Asserts HTTP 200 + JSON-RPC result (not error) + the returned peer set literally contains the other provisioned sibling IDs (not empty, not a native-sessions fallback). - Scoped teardown only of the e2e-pv-<run_id> org this run created (script EXIT trap + workflow always() net + sweep-stale-e2e-orgs as the final 'e2e-' prefix net) — never a cluster-wide cleanup. Honest gate, NO continue-on-error: it is RED on today's broken behavior by design and goes green only when the in-flight Hermes-401 + OpenClaw-MCP-wiring root-cause fixes actually land. Landed NON-required (not in branch_protections) so it does not wedge unrelated merges while red; flip-to-required checklist tracked in molecule-core#1296. Gitea-1.22.6 / act_runner hardening honored: mirrored actions/checkout SHA (the one e2e-staging-canvas.yml uses successfully), per-SHA concurrency, workflow-level GITHUB_SERVER_URL, no cross-repo uses. Passes lint-workflow-yaml, lint-continue-on-error-tracking, lint-required-no-paths locally. Refs: molecule-core#1296 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-15 23:08:56 -07:00
hongming-codex-laptop	ee55473812	test(e2e): workspace broadcast and talk-to-user abilities ... 20-assertion shell E2E covering the full abilities contract: - talk_to_user_enabled=true (default) → POST /notify succeeds - PATCH /abilities to disable → /notify returns 403 with error code and delegate_task hint; re-enabling restores delivery - broadcast_enabled=false (default) → POST /broadcast returns 403 - PATCH /abilities to enable → fan-out succeeds, delivered count >= 1 - Receiver activity log has broadcast_receive row (activity_type) with correct summary and source_id pointing at sender workspace - Sender activity log has broadcast_sent row; sender has no self-receive - Empty broadcast message returns 400 - Partial PATCH leaves unmentioned flags unchanged Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-05-15 12:03:08 -07:00
hongming-codex-laptop	4491b07add	ci: narrow status reaper soft skip to commit listing	2026-05-13 21:41:58 -07:00
hongming-codex-laptop	3b47c974ee	ci: stop operational push jobs painting main red	2026-05-14 04:41:10 +00:00