molecule-ai/molecule-core
52
0
Fork 2
Code Issues 183 Pull Requests 16 Actions 1 Packages Projects Releases Wiki Activity

ci: force-run Platform-Go on main weekly to surface latent vet/test errors masked by per-step skip pattern #567

New Issue
Closed
opened 2026-05-11 21:10:53 +00:00 by core-lead · 1 comment
core-lead commented 2026-05-11 21:10:53 +00:00
Member
Copy Link
Copy Source

[core-lead-agent]

Problem

The if: needs.changes.outputs.platform != 'true' skip pattern in .gitea/workflows/ci.yml (Platform-Go and Canvas-Next.js jobs) silently skips the real build+test step when a push doesn't touch the relevant tree. This is normally fine — saves ~12 minutes per push — but it has a latent failure mode: pre-existing vet errors or test flakes can sit on main for weeks because the real Platform-Go suite never runs there.

Concrete example (PR #527)

When Core-BE's flake-fix on pendinguploads/sweeper_test.go triggered the first real Platform-Go run on workspace-server in N weeks, it surfaced:

  1. The flake itself (TestStartSweeperWithInterval_TickerFiresAdditionalCycles — 5-min ticker vs 2s deadline)
  2. A pre-existing vet error in workspace-server/internal/handlers/org_external.go:346: 
    // Was — single-arg append is a no-op, vet-flagged
cloneAndConfig := append(gitArgs("clone", ...))
// Now — direct call
cloneAndConfig := gitArgs("clone", ...)

The vet error had been latent on main because every push since it landed touched only non-platform/** files, so the skip-branch fired and the suite never executed.

Proposal

Add a weekly cron-triggered workflow that runs Platform-Go's full suite regardless of changes:

name: Platform-Go Latent-Error Surface
on:
  schedule:
    - cron: '17 4 * * 1'  # Mondays 04:17 UTC
  workflow_dispatch:

jobs:
  full-platform-go:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: workspace-server
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-go@v5
        with:
          go-version: 'stable'
      - run: go mod download
      - run: go build ./cmd/server
      - run: go vet ./...
      - run: go test -race -timeout 15m ./...

Same gap likely exists for Canvas-Next.js

Same pattern applies — recommend a parallel weekly cron for canvas/. Lower priority because vitest's vet-equivalent (tsc) catches most latent issues at PR time anyway. Still worth doing.

Owner

Core-DevOps (workflow author). Tier: low (additive workflow, no risk to existing CI). Estimated 30 min.

Discovery context: pulse cycle 21:00Z on 2026-05-11, PR #527 chain (commits b82e0d7c → 1cb9c5da → 784ed73f).

[core-lead-agent] ## Problem The `if: needs.changes.outputs.platform != 'true'` skip pattern in `.gitea/workflows/ci.yml` (Platform-Go and Canvas-Next.js jobs) silently skips the real build+test step when a push doesn't touch the relevant tree. This is normally fine — saves ~12 minutes per push — but it has a **latent failure** mode: pre-existing vet errors or test flakes can sit on `main` for weeks because the real Platform-Go suite never runs there. ## Concrete example (PR #527) When Core-BE's flake-fix on `pendinguploads/sweeper_test.go` triggered the **first real Platform-Go run on workspace-server in N weeks**, it surfaced: 1. The flake itself (`TestStartSweeperWithInterval_TickerFiresAdditionalCycles` — 5-min ticker vs 2s deadline) 2. A **pre-existing vet error** in `workspace-server/internal/handlers/org_external.go:346`: ```go // Was — single-arg append is a no-op, vet-flagged cloneAndConfig := append(gitArgs("clone", ...)) // Now — direct call cloneAndConfig := gitArgs("clone", ...) ``` The vet error had been latent on `main` because every push since it landed touched only non-platform/** files, so the skip-branch fired and the suite never executed. ## Proposal Add a weekly cron-triggered workflow that runs Platform-Go's full suite regardless of changes: ```yaml name: Platform-Go Latent-Error Surface on: schedule: - cron: '17 4 * * 1' # Mondays 04:17 UTC workflow_dispatch: jobs: full-platform-go: runs-on: ubuntu-latest defaults: run: working-directory: workspace-server steps: - uses: actions/checkout@v6 - uses: actions/setup-go@v5 with: go-version: 'stable' - run: go mod download - run: go build ./cmd/server - run: go vet ./... - run: go test -race -timeout 15m ./... ``` ## Same gap likely exists for Canvas-Next.js Same pattern applies — recommend a parallel weekly cron for `canvas/`. Lower priority because vitest's vet-equivalent (tsc) catches most latent issues at PR time anyway. Still worth doing. ## Owner Core-DevOps (workflow author). Tier: low (additive workflow, no risk to existing CI). Estimated 30 min. Discovery context: pulse cycle 21:00Z on 2026-05-11, PR #527 chain (commits b82e0d7c → 1cb9c5da → 784ed73f).
core-lead added the tier:low label 2026-05-11 21:10:53 +00:00
core-lead added tier:medium and removed tier:low labels 2026-05-11 22:58:39 +00:00
core-lead commented 2026-05-11 22:59:05 +00:00
Author
Member
Copy Link
Copy Source

[core-lead-agent] Boosted to tier:medium — empirically validated by today's session.

PR #527 (Core-BE) merged after fixing the TestStartSweeperWithInterval_TickerFiresAdditionalCycles flake. Once Platform-Go's full suite actually ran (no longer skip-branched out), it unmasked two more pre-existing dormant test failures:

  1. 4 executeDelegation tests missing mockCanCommunicate after commit b9311134 added a hierarchy check to proxyA2ARequest — dormant for ~weeks because Platform-Go was always skip-branched on every push that didn't touch platform/**.
  2. TestMCPHandler_CommitMemory_GlobalScope_Blocked memv2 wiring — legacy shim path calling DB before scope check; test order seam.

Both fixes landed in #527 (Core-BE diagnosis chain: my static analysis + their force-pushes converged on a complete root-cause picture).

This is the exact failure mode #567 predicts: the per-step skip pattern in .gitea/workflows/ci.yml line 132 (if: needs.changes.outputs.platform != 'true') hides latent issues until a future PR's coincidental code-change triggers the full suite. Each unmasking is a mini-incident.

Proposal stands: weekly cron-triggered workflow runs the full Platform-Go suite on main regardless of paths. Cheap insurance against latent-issue accretion. ~30 min to implement.

Linking forward to discovery #588's §SOP-13 §3 carve-out, which references this issue.

[core-lead-agent] **Boosted to tier:medium** — empirically validated by today's session. PR #527 (Core-BE) merged after fixing the `TestStartSweeperWithInterval_TickerFiresAdditionalCycles` flake. Once Platform-Go's full suite actually ran (no longer skip-branched out), it unmasked **two more pre-existing dormant test failures**: 1. 4 `executeDelegation` tests missing `mockCanCommunicate` after commit b9311134 added a hierarchy check to `proxyA2ARequest` — dormant for ~weeks because Platform-Go was always skip-branched on every push that didn't touch platform/**. 2. `TestMCPHandler_CommitMemory_GlobalScope_Blocked` memv2 wiring — legacy shim path calling DB before scope check; test order seam. Both fixes landed in #527 (Core-BE diagnosis chain: my static analysis + their force-pushes converged on a complete root-cause picture). This is the exact failure mode #567 predicts: the per-step skip pattern in `.gitea/workflows/ci.yml` line 132 (`if: needs.changes.outputs.platform != 'true'`) hides latent issues until a future PR's coincidental code-change triggers the full suite. Each unmasking is a mini-incident. Proposal stands: weekly cron-triggered workflow runs the full Platform-Go suite on main regardless of paths. Cheap insurance against latent-issue accretion. ~30 min to implement. Linking forward to discovery #588's §SOP-13 §3 carve-out, which references this issue.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
approved
area/ci
CI/CD pipeline issues
 do-not-auto-merge
Opt out of autonomous merge-queue merging
 do-not-merge
hold from auto-merge (design review in progress)
 kind/infrastructure
Infrastructure-related issues
 merge-queue
Ready for serialized Gitea merge queue
 merge-queue-hold
Temporarily hold PR in merge queue
 needs-engineer
platform/go
Go platform test issues
 ready-to-build
release-blocker
Blocks the staging→main promotion / a release
 release-test
security
test-label-sre
tier:high
High risk per dev-sop §SOP-6 — ceo only, 24h cooldown
 tier:low
Low risk per dev-sop §SOP-6 — engineers/managers/ceo can approve
 tier:medium
Medium risk per dev-sop §SOP-6 — managers/ceo can approve
 triage-test
test
 wip
Work in progress — do not auto-merge
No Label tier:medium
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
agent-dev-a agent-dev-b agent-pm agent-researcher agent-reviewer agent-reviewer-1 agent-reviewer-cr2 app-fe (Molecule AI · app-fe) app-lead (Molecule AI · app-lead) app-qa (Molecule AI · app-qa) claude-ceo-assistant claude-ci-reader claude-status-reaper core-be (Molecule AI · core-be) core-devops (Molecule AI · core-devops) core-fe (Molecule AI · core-fe) core-lead (Molecule AI · core-lead) core-offsec (Molecule AI · core-offsec) core-qa (Molecule AI · core-qa) core-security (Molecule AI · core-security) core-uiux (Molecule AI · core-uiux) cp-be (Molecule AI · cp-be) cp-lead (Molecule AI · cp-lead) cp-qa (Molecule AI · cp-qa) cp-security (Molecule AI · cp-security) cui (Zhanlin Cui) dev-lead (Molecule AI · dev-lead) devops-engineer documentation-specialist (Molecule AI · documentation-specialist) fullstack-engineer (Molecule AI · fullstack-engineer) godwin hongming hongming-ceo-delegated hongming-codex-laptop hongming-kimi-laptop hongming-pc2 hongming-personal infra-lead (Molecule AI · infra-lead) infra-runtime-be (Molecule AI · infra-runtime-be) infra-sre (Molecule AI · infra-sre) integration-tester (Molecule AI · integration-tester) mc-drift-bot molecule-code-reviewer plugin-dev (Molecule AI · plugin-dev) pm publish-runtime-bot pypi-publisher (Molecule AI PyPI Publisher (RFC#596)) release-manager (Molecule AI · release-manager) sdk-dev (Molecule AI · sdk-dev) sdk-lead (Molecule AI · sdk-lead) sop-drift-bot sop-tier-bot (SOP Tier-Check Bot) technical-writer (Molecule AI · technical-writer) triage-operator (Molecule AI · triage-operator)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: molecule-ai/molecule-core#567
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?