5428 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
Molecule AI Core-BE	4530b67336	fix(handlers): raw TCP mock server with proper request-body drain ... Abandon httptest+Hijack — it has two fundamental problems for this use case: 1. Buffered-writer loss: httptest's Hijack() discards the buffered writer, losing any bytes written via w.WriteHeader/w.Write that weren't already flushed to the raw conn. The HTTP client never receives response headers, blocking on ResponseHeaderTimeout=180s (the 2m8s hang). 2. Request-read deadlock: Go's httptest server keeps a read goroutine waiting for the request body after the handler returns. Calling Hijack() while that goroutine is still waiting causes a deadlock with the client's request-body writer. Fix: use raw TCP with net.Listener directly. The server: 1. Accepts one connection. 2. Reads HTTP request headers (blank line terminates). 3. Drains Content-Length bytes from the connection (prevents broken-pipe on client request-body writer when we close). 4. Writes raw HTTP response directly to the raw conn (no buffered writer). 5. Brief sleep so client reads headers+body before FIN fires. 6. Close() sends FIN → client Read() returns io.EOF. Also add allowLoopbackForTest() to each test so the SSRF guard permits 127.0.0.1 mock server URLs (same pattern as a2a_proxy_test.go). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-12 13:19:19 +00:00
Molecule AI Core-BE	2198b874bf	fix(handlers): write raw HTTP response after Hijack to bypass buffered writer ... Root cause of the 2m8s hang (which matched ResponseHeaderTimeout=180s): httptest's Hijack() discards the buffered writer, losing any bytes written via w.WriteHeader/w.Write that weren't already flushed to the raw TCP conn. The HTTP client therefore never receives response headers, blocking on ResponseHeaderTimeout (3 min). Fix: write the raw HTTP response directly to the raw conn AFTER Hijack(), completely bypassing httptest's buffered writer. This ensures: - Response headers reach the client immediately (not lost to buffered writer) - Client starts reading the response body - conn.Close() fires while client is mid-read → Read() returns EOF/error - executeDelegation completes in seconds, not minutes Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-12 13:11:18 +00:00
Molecule AI Core-BE	404b5482e4	fix(handlers): do not touch r.Body before Hijack in mockAgentWithPartialBody ... Closing r.Body triggers the Go HTTP server's pipe mechanism to signal EOF to the request-body reader. On the CLIENT side, this causes the request-body writer goroutine to fail with "read from closed pipe", which hangs the HTTP request indefinitely (until TCP-level timeouts fire). Fix: remove all r.Body access. Just Hijack() + conn.Close() and return. Matching the exact pattern from a2a_proxy_test.go TestProxyA2A_BodyReadFailure_DeliveryConfirmed. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-12 13:00:46 +00:00
Molecule AI Core-BE	52227bc92d	fix(handlers): remove r.Body drain from mockAgentWithPartialBody ... The previous httptest.Server implementation called io.Copy(io.Discard, r.Body) before Hijack(), which caused a 3-minute hang: the handler blocked waiting to finish reading the request body while the HTTP client was blocked writing the body (waiting for response headers that the handler hadn't sent yet). This is a classic deadlock. Fix: match the existing a2a_proxy_test.go pattern — do NOT read r.Body before Hijack(). The HTTP parser has already consumed request headers; the body may still be in flight from the client. The server closes r.Body when the handler returns (server-managed), and conn.Close() after Hijack() fires RST/EOF to the client, which is the desired "connection drop" simulation. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-12 12:56:38 +00:00
Molecule AI Core-BE	6af5ca4d5e	ci: re-trigger handlers postgres integration workflow ... [core-be-agent]	2026-05-12 12:49:50 +00:00
Molecule AI Core-BE	99b8763524	fix(handlers): replace raw TCP mock with httptest.Server+Hijack in integration tests ... The raw TCP mock servers used in tests 1-3 caused 5-minute CI timeouts. The issue was two-fold: 1. defer conn.Close() fired before the kernel TCP send buffer was drained, so HTTP headers never reached the client and it blocked forever waiting. 2. Even with an explicit 200ms sleep before Close(), the CI environment under load sometimes didn't drain the buffer in time, causing the 5-minute idle timeout (A2A_IDLE_TIMEOUT_SECONDS) to fire. Switch to httptest.Server with http.Hijack(): - httptest.Server handles the HTTP listener lifecycle properly. - Hijack() gives direct access to the raw TCP connection after HTTP headers are parsed, bypassing the buffered writer. - Flush() before Hijack() ensures data reaches the kernel TCP buffer. - Immediate conn.Close() after Flush() triggers a read error on the HTTP client (connection reset / EOF) even though headers arrived. This matches the pattern already proven in a2a_proxy_test.go for similar partial-body connection-drop scenarios. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-12 12:30:34 +00:00
Molecule AI Core-BE	65d1db6c5e	fix(handlers): ensure mock TCP server transmits data before closing ... Bug: raw-TCP mock servers in integration tests used `defer conn.Close()` which fires immediately after `conn.Write` (buffered in kernel send buffer). The connection closed before the kernel TCP stack finished transmitting the response, so the Go HTTP client hung waiting for response headers that never arrived. Test 1 (200 + partial body) timed out at the 5-minute idle timeout: - mock server: Accept → Read → Write(135B) → defer Close → goroutine exits - client: sent request, waited forever for response headers - isDeliveryConfirmedSuccess path never reached Tests 2-3 (500 / empty body) passed in 500ms because the 500ms test-body-timeout caught the hanging goroutine. Fix is the same for all three: write the response, sleep 200ms (kernel TCP transmits), *then* close. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-12 12:15:08 +00:00
Molecule AI Core-BE	164030ed14	fix(handlers): pass correct mock-server URL to setupIntegrationRedis ... Root cause of 5-minute timeout: setupIntegrationRedis seeded Redis with http://bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb (the UUID as hostname), which the Go http.Client cannot resolve. The SSRF validation passes (valid DNS hostname) but DNS resolution fails → HTTP request hangs for the client's default 60s timeout before retrying → test times out at 5m. Fix: change setupIntegrationRedis(t) → setupIntegrationRedis(t, agentURL) so each test passes the actual mock server address (http://127.0.0.1:PORT) before the function caches it. Remove the redundant db.RDB.Set override in Test1 (URL now correct from the start). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-12 11:49:38 +00:00
Molecule AI Core-BE	fa2b1d78fc	fix(handlers): initialize db.RDB before executeDelegation in integration tests ... RecordAndBroadcast (called by executeDelegation) calls db.RDB.Publish(), which panics when db.RDB is nil. Fix: - Add setupIntegrationRedis() helper that starts miniredis, sets db.RDB, and seeds the target workspace URL via db.CacheURL - Call setupTestRedis() directly in the Redis-down test (no URL cached, so resolveAgentURL falls back to DB which also has no URL → target unreachable) - Import db and redis packages Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-12 11:37:36 +00:00
Molecule AI Core-BE	c831199562	fix(handlers): use valid UUIDs for workspace seeds in integration tests ... workspaces.id is UUID-typed. The string IDs like "ws-source-159-integration" caused: pq: invalid input syntax for type uuid Fix: use real UUIDs (AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA / BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB) matching the pattern in delegation_ledger_integration_test.go. Also add the required 'name' column (NOT NULL) to the INSERT. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-12 11:24:19 +00:00
Molecule AI Core-BE	7ae80d3ed4	fix(handlers): remove unused os and mdb imports in integration test ... Both packages were imported but not referenced in the file. Go build tag "integration" still compiles them — caught by CI. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-12 11:11:00 +00:00
Molecule AI Core-BE	bb993ec5a8	test(handlers): migrate 4x executeDelegation tests to real-Postgres integration ... mc#664 Class 1: Replace 4 sqlmock-based TestExecuteDelegation_* tests (+ 3 expectExecuteDelegation* helpers) in delegation_test.go with 5 real-Postgres integration tests in delegation_executor_integration_test.go. Deleted: - expectExecuteDelegationBase/Success/Failed helpers (sqlmock-only) - TestExecuteDelegation_DeliveryConfirmedProxyError_TreatsAsSuccess - TestExecuteDelegation_ProxyErrorNon2xx_RemainsFailed - TestExecuteDelegation_ProxyErrorEmptyBody_RemainsFailed - TestExecuteDelegation_CleanProxyResponse_Unchanged Added (delegation_executor_integration_test.go): - TestIntegration_ExecuteDelegation_DeliveryConfirmedProxyError_TreatsAsSuccess — 200 with partial body → 'completed' (isDeliveryConfirmedSuccess guard) - TestIntegration_ExecuteDelegation_ProxyErrorNon2xx_RemainsFailed — 500 with partial body → 'failed' (status>=200&&<300 guard fails) - TestIntegration_ExecuteDelegation_ProxyErrorEmptyBody_RemainsFailed — 200 with empty body → 'failed' (len(body)>0 guard fails) - TestIntegration_ExecuteDelegation_CleanProxyResponse_Unchanged — clean 200 → 'completed' (baseline) - TestIntegration_ExecuteDelegation_RedisDown_FallsBackToDB — no Redis → graceful failure (not panic) Each integration test verifies the delegations table state end-to-end, which sqlmock cannot cover (drift in last_outbound_at UPDATE, lookupDeliveryMode/Runtime SELECTs, a2a_receive INSERT, recordLedgerStatus writes — mc#664 root cause). The existing Handlers Postgres Integration CI job picks up the new TestIntegration_* tests automatically. Closes: #686 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-12 10:57:16 +00:00
hongming-pc2	a9351ae47d	Merge pull request 'fix(handlers): OFFSEC-001 — scrub req.Method from dispatchRPC default error (hotfix)' (#705) from fix/offsec-001-method-scrub-main into main	2026-05-12 08:47:33 +00:00
Molecule AI Fullstack Engineer	4dce9800a5	fix(handlers): OFFSEC-001 — scrub req.Method from dispatchRPC default error ... Line 443 of mcp.go concatenated user-controlled req.Method into the JSON-RPC -32601 error message, allowing an agent or canvas client to inject arbitrary strings into the response via the method field. Fix: replace "method not found: " + req.Method with the constant "method not found" — matching the OFFSEC-001 scrub contract applied to the InvalidParams (line 428) and UnknownTool (line 433) paths. Test: extend TestMCPHandler_UnknownMethod_Returns32601 with two new assertions: 1. resp.Error.Message == "method not found" 2. defence-in-depth check that the sent method name never appears in the response (strings.Contains guard) Issue: #684 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-12 08:28:39 +00:00
Molecule AI · core-devops	11fc33a55f	Merge pull request 'feat(ci)(hard-gate): lint-pre-flip catches continue-on-error true→false without run-log proof' (#673) from infra/lint-pre-flip-continue-on-error into main	2026-05-12 08:04:56 +00:00
Molecule AI Core-DevOps	ebeea0a9c1	fix(workflows): add mc#664 tracker to lint-pre-flip CoE directive ... lint-continue-on-error-tracking (Tier 2e) requires a tracker within ±2 lines of every `continue-on-error: true`. The inline comment was 3 lines above the directive, outside the scan window. Move mc#664 to an inline comment on the directive line so it is within ±2 lines (WINDOW=2 per lint_continue_on_error_tracking.py). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-12 07:38:13 +00:00
Molecule AI Core-DevOps	0970feef70	feat(ci)(hard-gate): lint-pre-flip catches continue-on-error true→false without run-log proof ... Empirical class — PR #656 / mc#664: PR #656 (RFC internal#219 Phase 4) flipped 5 platform-build-class jobs `continue-on-error: true → false` on the basis of a "verified green on main via combined-status check". But that "green" was the LIE the prior `continue-on-error: true` produced: Gitea Quirk #10 (internal#342 + dup #287) — a failed step inside a CoE:true job rolls up to a success job-level status. The precondition the PR claimed to verify was structurally fooled by the bug being flipped. mc#664 captured the surfaced defects (2 mutually-masked regressions): - Class 1: sqlmock helper drift since 2f36bb9a (24 days old) - Class 2: OFFSEC-001 contract collision since 7d1a189f (1 day old) Codified 04:35Z as hongming-pc2 charter §SOP-N rule (e) "run-log-grep-before-flip": pull the actual run log + grep for --- FAIL / FAIL\s BEFORE flipping; don't trust the masked combined-status. This commit structurally enforces that rule. What this PR adds: .gitea/workflows/lint-pre-flip-continue-on-error.yml — pre-merge pull_request gate, path-scoped to .gitea/workflows/**. Lands at continue-on-error:true (Phase 3 dogfood — flip to false in a follow-up only after this workflow has clean recent runs on main). .gitea/scripts/lint_pre_flip_continue_on_error.py — the lint: 1. Reads every .gitea/workflows/*.yml at the PR base SHA AND head SHA via git show <sha>:<path>. No checkout needed. 2. Parses both sides via PyYAML AST (per feedback_behavior_based_ast_gates — NOT grep, so comment churn and key-order changes don't false-positive). 3. For each flipped job (base=true, head=false), renders the commit-status context as "{workflow.name} / {job.name or job.key} (push)" and pulls combined commit-status for the last 5 commits on the PR base branch. 4. Fetches each matching run's log via the web-UI route {server_url}/{repo}/actions/runs/{run_id}/jobs/{job_idx}/logs (per reference_gitea_actions_log_fetch — Gitea 1.22.6 lacks REST /actions/runs/*; web-UI is the only working path, see reference_gitea_1_22_6_lacks_rest_rerun_endpoints). 5. Greps for --- FAIL / FAIL\s / ::error::. If status==success AND log shows fail markers, the job was masked. Emit ::error::file=... naming the failing test + offending run URL. .gitea/scripts/tests/test_lint_pre_flip_continue_on_error.py — 35 unittest cases covering the 5 acceptance tests from the spec + CoE coercion (truthy/falsy/quoted/absent) + context-name rendering + multi-flip aggregation + dry-run semantics + 3 graceful-degrade halt conditions (log-unavailable, zero-runs- history, zero-commits-on-branch). Live empirical confirmation: Ran the script against the PR#656 base→merge diff with RECENT_COMMITS_N=3 on main. Result: - platform-build flip BLOCKED — masked --- FAIL on TestExecuteDelegation_DeliveryConfirmedProxyError_TreatsAsSuccess + 4 more on action_run 13353. - canvas-build / shellcheck / python-lint flips PASS — no FAIL markers in their recent logs. Exactly the diagnosis hongming-pc2 charter §SOP-N rule (e) requires. Halt-condition graceful-degrade contract: - Log fetch 404 (act_runner pruned, transient outage): warn-not-block. - Zero recent runs of the flipped context (newly-added workflow): chicken-and-egg exemption — warn and allow. - YAML parse error in one workflow file: warn-not-block (the YAML lint workflows catch this separately). Cross-links: PR#656, mc#664, PR#665 (interim re-mask), Quirk #10 (internal#342 + dup #287), hongming-pc2 charter §SOP-N rule (e), feedback_strict_root_only_after_class_a, feedback_no_shared_persona_token_use. Refs: internal#342, internal#287, molecule-core#664, molecule-core#665	2026-05-12 07:27:19 +00:00
Molecule AI · core-devops	9eb33a9d3c	Merge pull request 'fix(ci): replace workflow_run triggers with push+paths (Gitea 1.22.6)' (#694) from fix/workflow_run-to-push-gitea-1.22.6 into main	2026-05-12 07:23:06 +00:00
Molecule AI Core-DevOps	2ee7cb1493	fix(ci): replace workflow_run triggers with push+paths (Gitea 1.22.6) ... Three workflows used `workflow_run:` to trigger when `publish-workspace-server-image.yml` completed, but Gitea 1.22.6 does not support the `workflow_run` event (task #81). The workflows were silently dead — never firing despite `continue-on-error: true`. Replaced each with `push: branches: [X], paths: [.gitea/workflows/ publish-workspace-server-image.yml]` which fires on every commit to the publish workflow. This is functionally equivalent: only successful runs commit to the branch. Also: - `redeploy-tenants-on-staging.yml`: corrected branch from [main] to [staging] (was wrong in the original Gitea port). - `staging-verify.yml`: removed `if: workflow_run.conclusion==success` since push events lack this context; the smoke test itself is the safety net. - Added `workflow_dispatch` to all three for manual runs. This fixes the 3 Rule-2 violations reported by lint-workflow-yaml (lint from #671). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-12 07:19:50 +00:00
Molecule AI · core-devops	84ec7fe728	Merge pull request 'feat(ci)(hard-gate): lint-continue-on-error-tracking (Tier 2e)' (#689) from feat/tier-2e-tracking-issue into main	2026-05-12 07:18:50 +00:00
core-devops	0dae4b8eb0	feat(ci)(hard-gate): lint-continue-on-error-tracking (Tier 2e) ... Every `continue-on-error: true` in `.gitea/workflows/*.yml` must carry a `# mc#NNNN` or `# internal#NNNN` tracker comment within 2 lines, referencing an OPEN issue ≤14 days old. The class this prevents ----------------------- `continue-on-error: true` on platform-build had been hiding mc#664-class regressions for ~3 weeks before #656 surfaced them. A 14-day cap on tracker age forces a review cycle: close-or-renew. Implementation -------------- - `.gitea/scripts/lint_continue_on_error_tracking.py` — PyYAML line-tracking loader to find every job-level `continue-on-error: <truthy>`. Treats string `"true"` as truthy (Gitea evaluator coerces). For each, scans ±2 lines of the directive's source line for `# mc#NNN` / `# internal#NNN` (regex case-sensitive — `mc` and `internal` are conventional slugs). GETs each issue from the Gitea API; valid = exists + state=open + `age.days <= MAX_AGE_DAYS` (inclusive 14d boundary). Graceful-degrades on 403 (token-scope) per Tier 2a contract. - `.gitea/workflows/lint-continue-on-error-tracking.yml` — pull_request + push + daily 13:11Z schedule. Schedule run catches the age-expiry class (tracker was ≤14d when PR landed but is now 20d). Phase 3 (continue-on-error: true) per RFC #219 §1. - `tests/test_lint_continue_on_error_tracking.py` — 14 unit tests: coe=false ignored, open-recent mc#/internal# pass, no-comment fail, comment-too-far fail, closed-issue fail, too-old fail, 14d-boundary pass / 15d fail, 404 fail, 403 skip, multi-violation aggregation, comment-AFTER-directive pass, quoted "true" caught. Behaviour --------- Pre-existing continue-on-error: true directives on main violate this lint at first — intentional. They are the masked defects this lint exists to surface (see mc#664). Phase 3 contract means the lint runs surface-only; follow-up flip to continue-on-error: false after main is clean for 3 days. Auth uses DRIFT_BOT_TOKEN (same as ci-required-drift.yml) because `internal#NNN` references cross repositories — auto-GITHUB_TOKEN can't read molecule-ai/internal from molecule-core. Refs: #350	2026-05-12 07:05:07 +00:00
Molecule AI · core-devops	cc6fa8717d	Merge pull request 'feat(ci): sop-checklist-gate — peer-ack merge gate (RFC#351 Phase 2)' (#688) from feat/sop-checklist-gate-mvp into main	2026-05-12 07:03:49 +00:00
Molecule AI · core-devops	771a4b2a87	Merge pull request 'feat(ci)(hard-gate): lint-mask-pr-atomicity (Tier 2d)' (#685) from feat/tier-2d-lint-mask-pr-atomicity into main	2026-05-12 07:03:48 +00:00
core-devops	76988c05cd	fix(ci): sop-checklist-gate exits 0 by default — POSTed status is the gate ... By default the gate script now exits 0 in non-dry-run mode regardless of ack state. The job-level pass/fail must NOT carry the gate signal — otherwise BP sees TWO failure signals (the job-auto-status + our POSTed status) and the user gets ambiguous error messages. The POSTed `sop-checklist / all-items-acked (pull_request)` status IS the gate. Job conclusion is informational. Added --exit-on-state for local debugging (restores the old non-zero-on-failure behavior). Default OFF — production behavior is exit 0 always. 51/51 tests still pass. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-12 06:13:58 +00:00
core-devops	72df12ecef	feat(ci): sop-checklist-gate — peer-ack merge gate (RFC#351 Phase 2) ... RFC#351 Step 2 of 6: implementation MVP of the SOP-checklist peer-ack merge gate. NOT yet wired to branch protection (Phase 4 needs separate authorization). What: - .gitea/sop-checklist-config.yaml — 7-item checklist with slug, numeric_alias (1..7), pr_section_marker, required_teams. Includes tier-aware failure-mode map: tier:high/medium=hard, tier:low=soft, default=hard (never silently lower the bar). - .gitea/scripts/sop-checklist-gate.py — parses PR body + comments, computes per-item ack state, posts commit-status "sop-checklist / all-items-acked (pull_request)". - .gitea/scripts/tests/test_sop_checklist_gate.py — 51 unit tests covering slug normalization, directive parsing, section-marker detection, ack-state computation (self-ack reject, revoke semantics, multi-user/multi-item, numeric aliases), tier-mode selection, and end-to-end happy path. - .gitea/workflows/sop-checklist-gate.yml — pull_request_target [opened/edited/synchronize/reopened] + issue_comment [created/edited/deleted]. Checks out BASE ref only (trust boundary per RFC#324 §A4). Mirrors qa-review/security-review patterns. Why: Hongming 2026-05-12T05:42Z asked for SOP-enforcing CI/CD that requires peer-ack on each checklist item before merge. Composes the existing patterns (scripts-lint PR-body parser + RFC#324 persona-whitelist commit-status + sop-tier-check tier-awareness) into one gate. Slash-command contract: /sop-ack <slug> [note] — register peer-ack (most-recent wins) /sop-revoke <slug> [reason] — invalidate own prior ack Slug normalization accepts kebab-case, snake_case, natural-spaces, or numeric 1..7 shorthand (all canonicalize to kebab-case via the config-driven alias table). Tests: 51/51 pass locally. Dry-run probe against PR#685 verified the full pipeline (PR fetch, comment fetch, ack computation, status description rendering inside the 140-char budget). Not yet: - Phase 3 (24h soak) - Phase 4 (BP PATCH to require this context — needs Hongming GO) - Phase 5 (cross-repo) - Phase 6 (dev-sop.md codification) - SOP_CHECKLIST_GATE_TOKEN secret provisioning (separate follow-up; fail-closed until provisioned, same as RFC_324_TEAM_READ_TOKEN pattern in qa-review.yml). Cross-links: - internal#351 (RFC body) - RFC#324 (qa-review/security-review — reused mechanism) - internal#346 (dev-sop.md SOP-14..SOP-20 — sibling rules) - feedback_pull_request_review_no_refire (why issue_comment trigger) - feedback_checkpointed_workflow_over_good_practice_doc (motivation) - feedback_fix_root_not_symptom (default-mode=hard rationale) ## What Add a SOP-checklist peer-ack merge gate: workflow + script + config + 51 unit tests. ## Why Hongming-requested mechanism to enforce SOP via CI/CD: each PR checklist item must be peer-acked before merge, with team-membership-verified ackers and tier-aware failure mode. ## Verification - 51/51 unit tests pass (slug normalization, parse_directives, section marker detection, ack-state including self-ack rejection + revoke semantics, tier-mode mapping, end-to-end happy path). - YAML lint clean (yaml.safe_load + lint-workflow-yaml.py on the new workflow — pre-existing fatals on unrelated files only). - Python syntax clean (py_compile). - Dry-run against live PR#685: PR fetch, comment enumeration, status description render all within 140-char budget — works end-to-end. ## Tier tier:medium — net-new CI workflow; no production impact; no BP change yet (Phase 4 separate auth). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-12 06:08:36 +00:00
core-devops	75af96586d	feat(ci)(hard-gate): lint-mask-pr-atomicity (Tier 2d) ... Blocks PRs that touch `.gitea/workflows/ci.yml` and modify ONLY ONE of {continue-on-error, all-required.sentinel.needs} without a `Paired: #NNN` reference in the PR body or a commit message. The split-pair class this prevents ---------------------------------- PR#665 (interim continue-on-error: true on platform-build) and PR#668 (sentinel-needs demotion of the same job) were designed as a pair but merged solo: #665 landed 04:47Z 2026-05-12, #668 still open at 05:07Z when watchdog #674 fired. ~20 min of main red + a cascade of false-positives. mc#664 was the surfaced incident. Implementation -------------- - `.gitea/scripts/lint_mask_pr_atomicity.py` — reads ci.yml at BASE_SHA and HEAD_SHA via `git show`, parses both via PyYAML AST (per feedback_behavior_based_ast_gates — NOT grep). Predicates: 1. any jobs.*.continue-on-error value diff 2. jobs.all-required.needs set diff (order-insensitive) Both → atomic, OK. Neither → no risk, OK. Exactly one → require `Paired: #NNN` in PR body or `git log base..head`. - `.gitea/workflows/lint-mask-pr-atomicity.yml` — pull_request trigger with paths filter on ci.yml + the lint files. Phase 3 (continue-on-error: true) per RFC #219 §1 ladder; follow-up flip after 3 clean days on main. - `tests/test_lint_mask_pr_atomicity.py` — 9 unit tests covering all prod branches per feedback_branch_count_before_approving: neither predicate, both atomic, coe-only/no-pair fail, needs-only/no-pair fail, coe-only/pair-in-body pass, needs-only/pair-in-commit pass, non-numeric pair rejection, ci.yml unchanged skip, newly-added ci.yml skip. Refs: #350	2026-05-11 23:06:18 -07:00
Molecule AI · core-devops	b462270201	Merge pull request 'feat(ci)(hard-gate): lint-workflow-yaml catches Gitea-1.22.6-hostile shapes' (#671) from infra/lint-workflow-yaml-hostile-shapes into main	2026-05-12 05:53:01 +00:00
core-devops	d57ed520f0	feat(ci)(hard-gate): lint-workflow-yaml catches Gitea-1.22.6-hostile shapes ... Tier-2 hardening per RFC internal#219 §1 + charter §SOP-N rule (m). New CI lint that scans .gitea/workflows/*.yml for six structurally-hostile shapes that Gitea 1.22.6 silently rejects or ambiguously parses, BEFORE they reach main. Rules (4 fatal + 1 fatal cross-file + 1 heuristic-warn): 1. on.workflow_dispatch.inputs — Gitea 1.22.6 mis-parses inputs.X as sibling event types and rejects the entire workflow with [W] ignore invalid workflow ... unknown on type. Memory: feedback_gitea_workflow_dispatch_inputs_unsupported. Origin: 2026-05-11 publish-runtime-v1.0.0 silent freeze, ~24h PyPI lag. 2. on: workflow_run — not enumerated in Gitea 1.22.6 event types (verified via modules/actions/workflows.go; task #81). Workflow registers, fires for zero events. 3. workflow name: containing / — breaks the commit-status convention <workflow> / <job> (<event>) used by sop-tier-check + status-reaper to tokenize context strings. 4. cross-file name: collision — status-routing is by name; collision yields undefined commit-status updates (status-reaper rev1 class). 5. cross-repo uses: org/repo/subpath@ref — DEFAULT_ACTIONS_URL=github resolves to github.com/<org-suspended>/... and 404s. Memory: feedback_gitea_cross_repo_uses_blocked. Cross-link: task #109. 6. (WARN, heuristic) api.github.com refs without workflow-level env.GITHUB_SERVER_URL. Memory: feedback_act_runner_github_server_url. Per halt-condition 3: downgraded to warn-not-fail to avoid the 3 known benign hits on current main (OCI source label + jq-release pin) which use https://github.com/... not https://api.github.com/. Empirical history this hardens against: - status-reaper rev1 caught rule-4 (name-collision) class fail-loud - sop-tier-refire DOA-d on rule-2 (workflow_run partial) - #319 bootstrap-paradox (chained-defect class, related) - internal#329 dispatcher race (adjacent) - 2026-05-11 publish-runtime: rule-1, 24h PyPI freeze on runtime-v1.0.0 publish Triggers: - pull_request — pre-merge gate - push to main/staging — post-merge regression catch even if the PR gate is bypassed by branch-protection drift Per RFC #219 §1 contract: continue-on-error: true on the job during the surface-broken-shapes phase. Follow-up PR flips off after the 3 existing rule-2 violations on main are migrated to a supported trigger. Existing-on-main violations surfaced by this lint (3, informational, NOT auto-fixed per halt-condition 2): - .gitea/workflows/redeploy-tenants-on-main.yml — rule 2 - .gitea/workflows/redeploy-tenants-on-staging.yml — rule 2 - .gitea/workflows/staging-verify.yml — rule 2 All three have on: workflow_run: triggers that will fire for zero events. Fix path: replace with cron or with push+paths:[upstream-yml] gate. Tracked separately (do not block this PR). Tests: tests/test_lint_workflow_yaml.py — 15 pytest cases: - 6 × per-rule violation-detected (rules 1-3,5 + rule 4 cross-file + rule 6 heuristic-warn) - 6 × per-rule clean-passes - 1 × cross-file collision detected - 1 × all-violations-aggregated single file - 1 × empty workflow dir = exit 0 - 1 × vendor-truth: the exact 2026-05-11 publish-runtime YAML shape from feedback_gitea_workflow_dispatch_inputs_unsupported is caught (per feedback_smoke_test_vendor_truth_not_shape_match: fixtures mirror real Gitea 1.22.6 semantics, not yaml-parser quirks) 15/15 tests pass locally. Lint exits 1 against current .gitea/workflows/ because of the 3 existing rule-2 violations above; that is the gate working as intended (and continue-on-error keeps the PR-status soft until the violations are migrated).	2026-05-12 05:50:55 +00:00
Molecule AI · core-devops	966e5cf59c	Merge pull request 'feat(ci)(hard-gate): lint-required-workflows-no-paths-filter' (#670) from infra/lint-required-no-paths-filter into main	2026-05-12 05:50:36 +00:00
core-devops	c0f594cd22	feat(ci)(hard-gate): lint-required-workflows-no-paths-filter (structural enforcement of feedback_path_filtered_workflow_cant_be_required) ... Add `.gitea/workflows/lint-required-no-paths.yml` + supporting script and tests that fail a PR if any workflow whose status-check context appears in `branch_protections/main.status_check_contexts` carries a `paths:` or `paths-ignore:` filter in its `on:` block. Why --- A required-check workflow with a paths filter silently degrades the merge gate. If a PR's diff doesn't match the filter, the workflow never fires; Gitea (1.22.6) treats the required context as `pending` (NOT `skipped == success`), so the PR cannot merge. A docs-only PR against `paths: ['**.go']` would be wedged forever — no human action produces a green. Previously this was prevented only by reviewer vigilance + the saved memory `feedback_path_filtered_workflow_cant_be_required`. This commit makes it a structural CI gate. Empirical baseline (verified 2026-05-11 against git.moleculesai.app/molecule-ai/molecule-core/branch_protections/main): status_check_contexts: - "Secret scan / Scan diff for credential-shaped strings (pull_request)" - "sop-tier-check / tier-check (pull_request)" - "CI / all-required (pull_request)" All three workflows (`secret-scan.yml`, `sop-tier-check.yml`, `ci.yml`) have NO paths/paths-ignore filter today. This lint locks that contract: a future PR adding `paths:` to any of them — or to any new required workflow per RFC#324 Step 2 (qa-review, security-review) — fails fast at PR time. How --- - Workflow runs on `pull_request: [opened, synchronize, reopened]` + `workflow_dispatch`. Deliberately NO `paths:` filter on itself — the workflow is self-evidently a meta-required-check. - Reads `branch_protections/main` via `DRIFT_BOT_TOKEN` (same secret ci-required-drift.yml uses — repo-admin scope required for the endpoint per Gitea 1.22.6). - Parses each context `<workflow_name> / <job_name> (<event>)`, walks `.gitea/workflows/*.yml` for a file whose `name:` matches, then YAML-AST-walks the `on:` block for `paths` / `paths-ignore` keys. Behavior-based gate per `feedback_behavior_based_ast_gates` — NOT grep-by-name, so reformatting / event moves still detect. - Token-scope fallback: if `branch_protections` returns 403/404, exits 0 with a loud `::error::` rather than red-X every PR. Token issues should be fixed at the token. Tests ----- 20 tests in `tests/test_lint_required_no_paths.py`, all green: - parse_context (3): standard, slash-in-job-name, malformed - resolve_workflow_file (2): match-by-name, missing - detect_paths_filters (8): clean, paths, paths-ignore, push.paths, both, on-string-shorthand, on-list-shorthand, on-event-null - run() end-to-end (7): empty contexts, clean workflow, paths fails, paths-ignore fails, unknown-context warns-not-fails, multi-required one-bad-one-good, protection-403 skip Live smoke (DRIFT_BOT_TOKEN against molecule-ai/molecule-core/main): all 3 required workflows clean — exit 0. Cross-links ----------- - `feedback_path_filtered_workflow_cant_be_required` (the rule now structurally enforced) - `feedback_behavior_based_ast_gates` (PyYAML AST walk, not grep) - ci-required-drift.yml (precedent for DRIFT_BOT_TOKEN reuse + branch_protections-read scope-fallback pattern) - Charter §SOP-N rule (f): required-checks must run unconditionally Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-12 05:48:22 +00:00
Molecule AI · core-uiux	18a32e1ad4	Merge pull request 'fix(canvas/mobile): remove ?? [] from Zustand selector to prevent infinite render loop' (#662) from fix/canvas-mobile-chat-loop into main	2026-05-12 05:26:02 +00:00
Molecule AI Core-UIUX	56945ffd49	fix(canvas/mobile): remove ?? [] from Zustand selector to prevent infinite render loop ... React error #185 (Maximum update depth exceeded) on mobile chat tab. Root cause: useCanvasStore((s) => s.agentMessages[agentId] ?? []) used a `?? []` fallback in the selector. Zustand uses Object.is for selector equality. When agentMessages[agentId] is undefined (initial state), the fallback creates a NEW [] reference on every store update. Zustand sees this as a state change and re-renders the component. The component reads from the store again, gets another new [] reference, and the cycle repeats until React hits the depth cap. Fix: remove `?? []` from the selector (returns undefined when no messages) and move the fallback to the useState initializer: storedMessages = useCanvasStore(selector) // returns undefined | T[] [messages] = useState(() => (storedMessages ?? []).map(...)) The useState initializer only runs once on mount, so the `?? []` there is safe — it creates the initial state once, then messages are managed via setMessages. Fixes issue #651. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-12 04:56:49 +00:00
Molecule AI · core-qa	d23bd286ce	Merge pull request 'fix(ci)(interim): re-add continue-on-error to platform-build (mc#664)' (#665) from fix/664-interim-remask-platform-build into main	2026-05-12 04:47:23 +00:00
Molecule AI Core-Lead	9aa2b13934	fix(ci)(interim): re-add continue-on-error to platform-build (mc#664 fix-forward in flight) ... Phase-3-masked test failures in workspace-server/internal/handlers/ surfaced when #656 (RFC internal#219 Phase 4) flipped platform-build continue-on-error from true to false on 0e5152c3. The pre-#656 main was masking these: 4x delegation_test.go (lines 1110/1176/1228/1271): TestExecuteDelegation_DeliveryConfirmedProxyError_TreatsAsSuccess TestExecuteDelegation_ProxyErrorNon2xx_RemainsFailed TestExecuteDelegation_ProxyErrorEmptyBody_RemainsFailed TestExecuteDelegation_CleanProxyResponse_Unchanged Root cause: expectExecuteDelegationBase/Success/Failed helpers do not mock the DB queries production has issued since ~2026-04-21: - UPDATE workspaces SET last_outbound_at (commit 2f36bb9a, 2026-04-18, async goroutine fired from logA2ASuccess in a2a_proxy_helpers.go) - SELECT delivery_mode / SELECT runtime FROM workspaces (lookup* in a2a_proxy_helpers.go since file split in 64ccf8e1, 2026-04-21) - INSERT INTO activity_logs (a2a_receive) via LogActivity in logA2ASuccess/logA2AError (preexisting, not mocked) - recordLedgerStatus writes (RFC #2829 #318) Symptoms: sqlmock unexpected query → production short-circuits → trailing ExpectExec for completed/failed never fires → mock.ExpectationsWereMet() reports unmet remaining expectations. 8.11s uniform wall time is the delegationRetryDelay × 2 attempts after the first unexpected-query causes a transient retry path. Halt cond #3 applies (>7 days masked → broader sweep needed; many subsequent commits stacked on top). 1x mcp_test.go:433 (TestMCPHandler_CommitMemory_GlobalScope_Blocked): Commit 7d1a189f (2026-05-10) hardened mcp.go:427 to scrub err.Error() from JSON-RPC error.Message (OFFSEC-001 / #259) — returning the constant string "tool call failed" instead. The test asserts the message contains "GLOBAL". Production-vs-test contract collision; needs a design call (revert OFFSEC scrub for this code class, or update the test to assert a different oracle e.g. captured logs / specific error code). Halt cond #2 applies (alternate-class finding, not sqlmock-mismatch). Time-boxed Option A (90 min sqlmock update) does not fit either failure class within scope. Choosing Option B per brief: interim re-mask of platform-build only — the other 4 #656 flips (changes, canvas-build, shellcheck, python-lint) retain continue-on-error: false. This is a sequenced revert→fix→reflip per feedback_strict_root_only_after_class_a emergency clause, NOT a permanent re-mask. mc#664 stays open as the fix-then-reflip tracker. Process note for charter SOP-N (companion to vendor-truth-review-discipline): before flipping a job continue-on-error: true → false, do not trust the combined-status "success" signal alone — pull the actual run log and grep for --- FAIL / FAIL <package> to confirm the tests really pass. The masked green on 0e5152c3 came from continue-on-error suppressing the per-job status to neutral, which the combined-status aggregator counted as not-failure. Cross-links: - mc#664 (hongming-pc2 04:35Z Phase-3-masked defect filing) - mc#656 (the flip that surfaced this; 0e5152c3 first commit to actually run the Go tests against internal/handlers/* since the silent stack-up began) - feedback_strict_root_only_after_class_a (revert→fix→reflip discipline) - feedback_return_contract_change_audit_caller_tests (mcp case applies) - feedback_no_such_thing_as_flakes (these are real bugs, not flakes) Evidence (run 17810 / job 33895 / task 34532 on 0e5152c3): - 5x --- FAIL lines confirmed in actions_log/molecule-ai/molecule-core/e4/34532.log - delegation_test.go:1110/1176/1228/1271: "unmet sqlmock expectations" - mcp_test.go:433: "error message should mention GLOBAL, got: tool call failed" Gitea 1.22.6 quirk #10 confirmation: per the run, job-level continue-on-error DID still allow the combined commit-status to show neutral/success when the job logically failed — so the #656 PR check showed green even with these underlying failures masked. Reproduced. Co-Authored-By: Hongming Wang <hongmingwang.rabbit@users.noreply.github.com>	2026-05-12 04:40:32 +00:00
Molecule AI · core-lead	0e5152c342	Merge pull request 'fix(ci): RFC internal#219 Phase 4 — all-required enforced, stable jobs hard-fail' (#656) from infra/622-force-merge-protection-fix into main	2026-05-12 04:18:19 +00:00
Molecule AI Core-DevOps	1719534bf3	fix(ci): RFC internal#219 Phase 4 — all-required sentinel enforced, stable jobs hard-fail ... Phase 4 of the force-merge protection fix (internal#219 §2). Changes: - audit-force-merge.yml REQUIRED_CHECKS: add CI / all-required (pull_request) — closes the audit gap; force-merge audit now checks ci/all-required. - ci.yml: flip continue-on-error: false on stable jobs (changes, platform-build, canvas-build, shellcheck, python-lint) — confirmed green on main 2026-05-12 combined-status check. The all-required sentinel (continue-on-error: true) will be flipped once branch protection PATCH lands (Owner-tier, delegated separately). NOT included in this PR (separate Owner-tier action required): - Branch protection PATCH: add ci/all-required as required check on main. Needed to make the sentinel actually block merges. Delegate to Core Platform Lead. Refs: molecule-core#622, molecule-core#623	2026-05-12 04:09:44 +00:00
claude-ceo-assistant	49355cf971	Merge pull request 'fix(ci): status-reaper rev4 reads per-context "status" key not "state" (compensation was unreachable since rev1)' (#652) from infra/status-reaper-rev4-status-key-fix into main	2026-05-12 03:52:04 +00:00
claude-ceo-assistant	f6477f87ff	Merge branch 'main' into infra/status-reaper-rev4-status-key-fix	2026-05-12 03:46:25 +00:00
Molecule AI Core-UIUX	0caafb85bc	test(canvas): ActivityTab + DetailsTab + DropTargetBadge (65 cases) (#647) ... Co-authored-by: Molecule AI Core-UIUX <core-uiux@agents.moleculesai.app> Co-committed-by: Molecule AI Core-UIUX <core-uiux@agents.moleculesai.app>	2026-05-12 03:45:48 +00:00
core-devops	5674b0e067	fix(ci): status-reaper rev4 reads per-context "status" key not "state" (compensation was unreachable since rev1) ... Schema asymmetry in Gitea 1.22.6 combined-status response: - top-level `combined.state` → uses key "state" - per-entry `combined.statuses[i].*` → uses key "status", NOT "state" Pre-rev4 the per-entry loop in reap() (and the matching is_red() / render_body() in main-red-watchdog) read `s.get("state")` only, which returned None on every real Gitea response → state coerced to "" → `"" != "failure"` guard preserved every entry → compensation path unreachable since rev1. Empirical proof (orchestrator probe 2026-05-12 03:42Z): GET /repos/molecule-ai/molecule-core/commits/210da3b1/status → 29 per-entry items, ALL have key "status", ZERO have key "state". status value distribution: {success:18, failure:8, pending:3}. rev3 production run 17516 reported preserved_non_failure=585=30*19.5 (every context across all 30 SHAs preserved, none compensated) despite the same SHAs showing ~25 real failures via direct probe. Fix is one line per call site: s.get("state") → s.get("status") or s.get("state") The `state` fallback is defensive — keeps rev1-3 fixtures green and absorbs a hypothetical future Gitea version that emits both keys. Sibling-script audit: - main-red-watchdog.py: same bug at 3 sites (filter in is_red, display in render_body, debug dict in run_once). Bundled here because the fix is structurally identical and the failure mode matches. - ci-required-drift.py: no per-entry status iteration. Clean. Test gap (rev1-3 fixtures mirrored the bug): All 42 reaper fixtures + 26 watchdog fixtures used "state" per entry — same wrong key. That's why rev1-3 tests stayed green while the production code was no-op. Logged under `feedback_smoke_test_vendor_truth_not_shape_match`. New tests (8 total: 4 reaper + 4 watchdog) explicitly use the vendor-truth `status` per entry. Hostile self-review: temporarily reverted the reaper fix and re-ran — new tests FAILED at exactly the predicted assertion `assert counters["compensated"] == 1` → proves they're load-bearing, not tautological. Cross-links: task #90 (orchestrator), task #46 (hongming-pc2 paired investigation) PR #618 (rev1), PR #633 (rev2), PR #650 (rev3 widened window)	2026-05-11 20:44:20 -07:00
Molecule AI · core-devops	07ed95fd14	Merge pull request 'fix(ci): make go vet hard-failing in weekly-platform-go (#567/#612 followup)' (#615) from infra/weekly-platform-go-vet-hard into main	2026-05-12 03:38:40 +00:00
Molecule AI Core-DevOps	1c9255125e	fix(ci): make go vet hard-failing in weekly-platform-go	2026-05-12 03:37:52 +00:00
claude-ceo-assistant	33e0f8e24b	Merge pull request 'fix(gitea): audit-force-merge.sh pipefail guard — same as sop-tier-check fix' (#649) from fix/audit-force-merge-pipefail into main	2026-05-12 03:34:57 +00:00
claude-ceo-assistant	f9214391fb	Merge branch 'main' into fix/audit-force-merge-pipefail	2026-05-12 03:34:13 +00:00
claude-ceo-assistant	2f51a6176d	Merge pull request 'fix(ci): status-reaper rev3 widens window 10->30 + raises watchdog timeout + re-enables both crons' (#650) from infra/status-reaper-rev3-widen-window into main	2026-05-12 03:31:04 +00:00
core-devops	fae62ac8c1	fix(ci): status-reaper rev3 widens window 10->30 + raises watchdog timeout + re-enables both crons ... Phase 1+2 evidence (rev2 PR#633, merged 01:48Z): 6/6 ticks post-merge with `compensated:0` despite ~25 known-stranded reds visible across those same 10 SHAs on direct probe ~30min later. Reaper run 17057 at 02:46Z explicitly logged: scanned 42 workflows; push-triggered=19, class-O candidates=23 status-reaper summary: {compensated:0, preserved_non_failure:185, scanned_shas:10, limit:10} Root cause: schedule workflows post `failure` to commit-status RETROACTIVELY 5-15 min after their merge. By the time reaper's next */5 tick lands, the stranded red is on a SHA that has already fallen OUTSIDE a 10-commit window during a burst-merge period. Reaper algorithm is correct; the lookback window is too narrow vs. the retroactive-failure-post lag. Three-in-one fix (atomic per hongming-pc2 GO 03:25Z): 1. `.gitea/scripts/status-reaper.py` DEFAULT_SWEEP_LIMIT 10 -> 30. Trades window-width-cheap for cadence-loady; kept `*/5` cron unchanged (avoiding `*/2` which would double runner load). 2. `.gitea/workflows/status-reaper.yml` Restore schedule cron block (revert mc#645 comment-out for THIS workflow only). Cron stays `*/5 * * * *`. 3. `.gitea/workflows/main-red-watchdog.yml` Restore schedule cron block (revert mc#645 comment-out) AND raise job-level `timeout-minutes: 5 -> 15`. Original 5min cap was producing cancels under runner-saturation latency, which fed the very `[main-red]` issues this workflow files (self-poisoning). 4. `tests/test_status_reaper.py` + test_default_sweep_limit_is_30 (contract pin) + test_reap_widened_window_catches_retroactive_failure: mocks 30 SHAs, plants the failing context on SHA[20] (depth strictly past rev2's window=10), asserts the compensation POST lands on that SHA. Existing tests retain explicit `limit=10` overrides and remain unchanged. Suite: 42/42 passed (was 40 + 2 new). Verification plan (post-merge, 10-15 min after merge / 2-3 cron ticks): - DB: SELECT id, status FROM action_run WHERE workflow_id= 'status-reaper.yml' ORDER BY id DESC LIMIT 5 -> all status=1 - Log via web UI: /molecule-ai/molecule-core/actions/runs/<index>/jobs/0/logs -> summary line should now show compensated > 0 with compensated_per_sha populated - Direct probe: pick a SHA in the last 30 main commits with class-O fails, GET /repos/molecule-ai/molecule-core/commits/{sha}/status -> compensated contexts now show state=success with description starting 'Compensated by status-reaper' If rev3 STILL shows compensated:0 after the window-widening, the diagnosis is wrong and a DIFFERENT bug needs to be uncovered (per hongming-pc2 caveat 03:25Z). Re-enabling the crons IS the diagnosis verification. Cross-links: - PR#618 (rev1, drop-concurrency, merge 4db64bcb) - PR#633 (rev2, sweep-recent-commits, merge e7965a0f) - PR#645 (interim disable, merge 4c54b590) — re-enable being reverted - task #90 (orch rev3 tracker) / task #46 (hongming-pc2 tracker) - feedback_brief_hypothesis_vs_evidence (empirical evidence above) - feedback_strict_root_only_after_class_a (3-in-one root fix vs. longer patching chain) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-11 20:29:06 -07:00
Molecule AI Infra-Runtime-BE	8c343e3ac4	fix(gitea): add || true guards to jq pipelines in audit-force-merge.sh ... Same root cause as sop-tier-check.sh (commit a1e8f46): when GITEA_TOKEN is empty or returns a non-JSON error page, the jq pipeline exits 1, triggering set -e and aborting before the SOP_FAIL_OPEN fallback can run. Added || true to all jq-piped variable assignments: - MERGE_SHA, MERGED_BY, TITLE, BASE_BRANCH, HEAD_SHA extractions (lines 52-56): guard against malformed/empty PR JSON - process-substitution in the status-check while loop (line 78): guard against empty/invalid STATUS response - FAILED_JSON construction (line 100): guard against empty FAILED_CHECKS array producing empty-pipeline jq failures Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-12 03:26:36 +00:00
Molecule AI · core-devops	b915f1bc2d	Merge pull request 'fix(ci): sop-tier-check gracefully handles empty/invalid token' (#635) from fix/sop-tier-check-token-graceful into main	2026-05-12 03:20:33 +00:00
Molecule AI Core-DevOps	df821c8258	fix(ci): sop-tier-check gracefully handles empty/invalid token ... SOP_FAIL_OPEN=1 was not preventing CI failures because three API calls with `set -euo pipefail` would abort the script before reaching the SOP_FAIL_OPEN exit block: 1. `WHOAMI=$(curl ... | jq -r ...)` — jq exits 1 on empty input, triggering set -e → script exits before SOP_FAIL_OPEN check. 2. `curl` for reviews — curl exits non-zero on 401 from empty token, triggering set -e → same problem. 3. `curl` for org teams list — same issue. Fix: add `|| true` to jq pipelines and `set +e` / `set -e` guards around curl calls that may fail with empty token. When SOP_FAIL_OPEN=1 and the token is invalid, the script now exits 0 instead of 1, preventing blocking CI failures on unconfigured runners. Refs: sop-tier-check failure on PRs #617, #621, #587, #562	2026-05-12 03:16:17 +00:00
Molecule AI · core-devops	0bc1381ffe	Merge pull request 'fix(ci): ci-required-drift handles 403/404 on protection endpoint gracefully' (#630) from infra/ci-required-drift-token-scope into main	2026-05-12 03:14:55 +00:00