recipe-maintainers/cc-ci
0
0
Fork 0
Code Issues 1 Pull Requests 3 Actions Packages Projects Releases Wiki Activity
Files
1ecae1ce27caefd880435accb88fcccbd845d4e4
cc-ci/machine-docs/DEFERRED.md

18 KiB
Raw Blame History

DEFERRED — items parked for operator input

The single canonical registry of things the loops have deliberately decided not to do autonomously, and that need operator input to move on. Filing here is the loops' explicit way of saying "we've considered this, we're not doing it on our own; the operator gets to decide if/when it comes back" — instead of a vague "Q4 follow-up" buried in a JOURNAL.

This list is open-ended. Items can sit here indefinitely; the operator reviews at their own pace. There is no obligation to close every item — many will reasonably stay deferred for the life of the project. Closing is operator-driven.

The Phase-4 cleanup pass should surface this list to the operator (so it's seen at least once before the build is called done) — but does not force closure.

Conventions

  • Append-only. Either loop may file; never edit/delete someone else's entry. Closing = check the box + a one-liner pointing to the commit / PR / operator decision.
  • Each entry should clearly say what the loops would need from the operator to lift the deferral (an opt-in flag, a resource decision, an architectural call, plain "go ahead and do it") — that's the actionable part for the operator skimming this list.
  • A "Re-entry trigger" / IDEA cross-link is optional — include when there's a natural mechanism (e.g. an opt-in flag in cc-ci-plan/IDEAS.md); not every deferral has one, and many legitimately don't.

Format (one item per entry)

### YYYY-MM-DD — <slug>
- [ ] **What:** <concrete description, link to file/test/spec>
- **Filed by:** <Builder|Adversary>, phase <id>
- **Reason for deferral:** <technical, scope, "more than needed for default CI", dependency>
- **Re-entry trigger:** <optional — what operator input / mechanism would bring it back>
- **Linked IDEA / BACKLOG:** <optional cross-ref>

Open deferrals

2026-05-28 — matrix-synapse compress_state.sh port

  • What: Port the upstream recipe-maintainer recipe-info/matrix-synapse/tests/compress_state.sh to a cc-ci functional test under tests/matrix-synapse/functional/. The original creates state groups WITHOUT edges (full snapshots — Synapse's bloat pattern), runs synapse_auto_compressor, and asserts row counts drop.
  • Filed by: Builder, phase 2 (Q4.1 matrix-synapse PARITY pass)
  • Reason for deferral: Needs N>>1 synthesized state groups on every fresh deploy. Cost/time tradeoff is real — too-small N loses the test's meaning (state-group bloat is by definition a large-state phenomenon), too-large N inflates per-run time. Defensible defer; operator-confirmed 2026-05-28: heavier than needed for default CI.
  • Re-entry trigger: the --extra opt-in flag (see linked IDEA) so this runs only when the operator explicitly asks for the heavy suite; or a dedicated long-running matrix instance.
  • Linked IDEA: cc-ci-plan/IDEAS.md — Optional --extra flag for heavy/operational tests.

2026-05-28 — matrix-synapse test_complexity_limit.sh port

  • What: Port recipe-info/matrix-synapse/tests/test_complexity_limit.sh — exercise Synapse's complexity-limit rejection of overly-complex events.
  • Filed by: Builder, phase 2 (Q4.1 matrix-synapse PARITY pass)
  • Reason for deferral: Load-test class; needs many-event setup. Operator-confirmed 2026-05-28: more than needed for a default matrix CI test.
  • Re-entry trigger: the --extra opt-in flag (linked IDEA).
  • Linked IDEA: cc-ci-plan/IDEAS.md — Optional --extra flag for heavy/operational tests.

2026-05-28 — matrix-synapse test_purge.sh port

  • What: Port recipe-info/matrix-synapse/tests/test_purge.sh — exercise the recipe's abra.sh db purge_history / db purge_room admin helpers.
  • Filed by: Builder, phase 2 (Q4.1 matrix-synapse PARITY pass)
  • Reason for deferral: Recipe-helper-script tests, not synapse-behaviour tests (orthogonal to default Phase-2 coverage). Operator-confirmed 2026-05-28: more than needed for a default matrix CI test.
  • Re-entry trigger: the --extra opt-in flag (linked IDEA) — so PRs touching the recipe's abra helper scripts can opt in to exercising them.
  • Linked IDEA: cc-ci-plan/IDEAS.md — Optional --extra flag for heavy/operational tests.

2026-05-28 — matrix-synapse media upload/download roundtrip

  • What: Add tests/matrix-synapse/functional/test_media_upload_roundtrip.py exercising /_matrix/media/v3/upload + /_matrix/media/v3/download/<server>/<media_id>.
  • Filed by: Builder, phase 2 (Q4.1 matrix-synapse PARITY pass)
  • Reason for deferral: Not in the Q4.1 first pass; the three currently-landed functional tests already cover Synapse's defining behaviour (register / room / message / federation).
  • Re-entry trigger: Phase-2 follow-up (a recipe-coverage breadth pass) OR a PR that touches Synapse's media subsystem.
  • Linked IDEA: —

2026-05-28 — lasuite-docs OIDC parity ports + create-a-doc deeper test

  • CLOSED @2026-05-28 by Builder commits 41ede13 (SSO-dep refactor: deps-after-generic tiers + tests/lasuite-docs/setup_custom_tests.sh hook + deps_creds fixture) and cd25f52 (functional/test_oidc_login.py parity port + functional/test_create_doc.py §4.3 prescribed create-a-doc + read-back). Both tests marked @pytest.mark.requires_deps. Cold-verifiable: RECIPE=lasuite-docs STAGES=install,custom cc-ci-run runner/run_recipe_ci.py → 5 custom tests PASS (incl. the two new ones), deploy-count=2 (recipe + keycloak dep). upload_conversion.py parity (.md/.docx upload+conversion via authenticated /api/v1.0/documents/<id>/upload) remains as a Phase-2 follow-up below.

2026-05-28 — cryptpad create-a-pad + content round-trip Playwright test — ✅ RESOLVED @2026-05-29

  • RESOLVED @2026-05-29 (Builder, commits 05d0dc1 test + 656b68b cold-timing fix). tests/cryptpad/playwright/test_pad_content_roundtrip.py lands the §4.3 create-pad → type → FRESH-context read-back, green in the full harness custom tier (/root/ccci-cryptpad-full3.log: install/upgrade/backup/restore/custom all pass; test_cryptpad_pad_content_survives_fresh_session PASSED; deploy-count=1; clean teardown). Mapped empirically against CryptPad 2026.2.0 (the prior deferral cited 5.7.0 fragility): editor in nested …/pad/ckeditor-inner.html; /pad/ DOES auto-create a fragment-keyed pad after ~15s cold init; patience-tuned (goto_with_retry + 240s hash-wait + reload). F2-9 (Adversary-owned) satisfied — left for the Adversary to close on cold-verify. (Detail below retained for audit.)
  • What: Add tests/cryptpad/playwright/test_pad_content_roundtrip.py — exercise the full "open /pad/, type uniquely-marked content, reload, assert marker survives in the decrypted pad" lifecycle. The §4.3 prescribed CryptPad test.
  • Filed by: Builder, phase 2 (Q3.4 cryptpad PARITY pass)
  • Reason for deferral: CryptPad's pad-creation flow is version-specific in the release under test (10.6.0+5.7.0). /pad/ does NOT auto-redirect to a fragment-keyed pad URL on visit; the UI selector for "new rich-text" varies across versions; three drafts each missed the right contract. The maximal subset that IS shipped (parity health_check + recipe-specific spa_assets
    • Playwright SPA-render with console-error filter) covers the same JS-pipeline initialization that create-a-pad relies on. F2-9 Adversary conditional sign-off granted with the explicit expectation this lifts before Phase-2 DONE.
  • Re-entry trigger: Adversary's F2-9 sign-off requires this lifts BEFORE Phase-2 DONE — must pin a stable CryptPad app-launch contract (e.g. /pad/?new=1 if supported, or a role-based Playwright accessibility-tree selector for "New Rich Text") + ship the create-and-read-back test. Q5.2 cold-sample MUST include this.
  • Linked IDEA: —

2026-05-28 — uptime-kuma create-a-monitor (§4.3 prescribed)

  • What: Add a test that completes uptime-kuma's first-run setup wizard via Socket.IO, logs in to obtain a JWT, creates a monitor (monitor add Socket.IO emit), and asserts the monitor appears in the listed-monitors response.
  • Filed by: Builder, phase 2 (Q4.8 uptime-kuma enrollment)
  • Reason for deferral: Requires a Socket.IO client primitive in runner/harness/ (uptime-kuma uses Socket.IO for ALL real-time updates including setup + monitor CRUD). Today's tests (parity health + Socket.IO handshake + SPA branding) cover the same handshake + bundle the setup-then-monitor flow would use; adding a full Socket.IO client is a substantial harness primitive worth deferring until either (a) another recipe also needs Socket.IO interaction or (b) the --extra flag lands so this can live in extra/.
  • Re-entry trigger: the --extra opt-in flag (linked IDEA) OR another recipe enrollment that requires Socket.IO client primitives in the harness (whichever comes first).
  • Linked IDEA: cc-ci-plan/IDEAS.md — Optional --extra flag for heavy/operational tests.

2026-05-28 — ghost create-a-post round-trip (§4.3 prescribed)

  • What: Add tests/ghost/functional/test_post_roundtrip.py exercising Ghost's admin setup + token-auth + POST /ghost/api/v3/admin/posts/ (create) + GET /ghost/api/v3/admin/posts/<id>/ (read back), asserting the post round-trips.
  • Filed by: Builder, phase 2 (Q4.4 ghost enrollment)
  • Reason for deferral: Requires Ghost's first-run owner-setup flow (POST /ghost/api/v3/admin/authentication/setup/ with per-run admin email+password as class-B run-scoped) + JWT token management for the admin API. The current 3 tests (parity health + content_api + admin_redirect) cover the same Ghost-server / API / admin-route surface; the create-post flow is the natural §4.3 deeper test and is doable, but adds setup state to manage. Reasonable to defer to the --extra flag rollout OR a Phase-2 follow-up specifically for Q4 deeper tests.
  • Re-entry trigger: the --extra opt-in flag (linked IDEA) OR a Q4 deeper-test pass before Phase-2 DONE if the Adversary calls for it (Phase-4 cleanup pass MUST review).
  • Linked IDEA: cc-ci-plan/IDEAS.md — Optional --extra flag for heavy/operational tests.

2026-05-28 — Q2.2 authentik enrollment + setup_authentik_realm SSO backend

  • What: Enroll authentik in cc-ci tests/ (mirror-and-enroll if not yet mirrored) + add a setup_authentik_realm (or equivalent provider-pluggable name) backend in runner/harness/sso.py mirroring the keycloak path; a dependent recipe should be able to declare DEPS = ["authentik"] and use the same harness.sso.setup_<provider>_* API.
  • Filed by: Adversary (F2-7, Q2 checkpoint) → migrated to DEFERRED.md by Builder
  • Reason for deferral: Q2.4 acceptance is already proven via keycloak; no Phase-2 dependent recipe yet REQUIRES authentik specifically (the lasuite-* recipes use keycloak; cryptpad's recipe-maintainer SSO test uses authentik but that parity port is already deferred above). The SSO harness's OIDC FLOW primitives (oidc_password_grant, assert_discovery_endpoint) are already provider-agnostic; only setup_keycloak_realm is keycloak-specific.
  • Re-entry trigger (NARROWED per operator SSO policy 2026-05-29): ONLY when a recipe genuinely REQUIRES authentik (cannot work under keycloak). Dropped the former triggers — cryptpad's OIDC is now tested under keycloak (its upstream uses authentik but keycloak is equally valid), and Phase-2 DONE is explicitly NOT gated on authentik (no "prove pluggability"/second-provider/ DONE-review trigger). keycloak is the default SSO provider for all recipe OIDC tests. See DECISIONS.md "SSO-provider policy".
  • Linked IDEA: —

2026-05-29 — heavy-recipe upgrade tier needs more host disk (28GB too small) — CLOSED @2026-05-29

  • CLOSED @2026-05-29: orchestrator resized the cc-ci VM disk; filesystem auto-grew to 64G (44G free, 30% used), infra healthy, warm keycloak up. The disk constraint is resolved. The heavy-recipe upgrade tiers are now runnable. Follow-on (now ACTIVE backlog, not a deferral): run lasuite-drive's FULL lifecycle incl. the upgrade tier GREEN + Adversary cold-verify for the Q3.2 gate (per the Adversary, the upgrade tier is no longer validly deferrable); then re-confirm immich/lasuite-meet/lasuite-docs upgrade tiers. Tracked under BACKLOG-2 Q3.2. UPDATE @2026-05-29: lasuite-drive full lifecycle (incl. upgrade tier) is now 3× green (commits a151489 install-time OIDC + 4b38b66 collabora-ready upgrade gate; logs r2/r3/r4); Q3.2 CLAIMED, awaiting Adversary. The upgrade tier converged cleanly at 64G disk with the collabora-ready gate (the old 28GB pull-overflow concern below is moot at 64G). Remaining follow-on: re-confirm immich/lasuite-meet/lasuite-docs upgrade tiers when those recipes' gates run.
  • What: The upgrade tier for the heaviest recipes cannot complete on the 28GB host. Proven on lasuite-drive: the prev→PR-head chaos upgrade crosses two multi-GB office image versions at once — onlyoffice/documentserver-de 9.2 → 9.3.1.2 (3.94GB each) + collabora/code 25.04.9.1.1 → 25.04.9.4.1 (~1GB) — so ~10GB of office images must coexist on disk during the in-place rolling update. The host has only ~14GB docker headroom over its ~13GB baseline (nix store ~9.6GB + infra images), so the PR-head pull hit 99% and the deploy failed. There is no harness mitigation (the prev images are running when the new must be pulled — cannot rmi a running image; nothing dangling to prune pre-upgrade). install/backup/restore/custom (single version, ~6GB) all fit and pass — only the upgrade tier overflows. Almost certainly also blocks the upgrade tier of other heavy recipes (lasuite-docs ships collabora; immich ships multi-GB ML images; lasuite-meet).
  • Filed by: Builder, phase 2 (Q3.2 lasuite-drive full-lifecycle attempt)
  • Reason for deferral: Class A1 EXTERNAL infra input — host disk size. Not improvisable; not a test-quality issue; the recipe legitimately bumps office image tags across releases.
  • Operator action to lift: grow the cc-ci host disk (resize the droplet volume + online-grow the filesystem) to give heavy-recipe upgrade tiers transient headroom — ~+20GB would comfortably cover the dual-office-version crossover and the rest of the heavy set. Then re-run the full lasuite-drive lifecycle (and re-confirm immich/lasuite-meet/lasuite-docs upgrade tiers).
  • Re-entry trigger: operator disk resize, OR Phase-2b pull-through cache + image-GC policy work.
  • Linked IDEA: cc-ci-plan/IDEAS.md (pull-through cache / Phase 2b).

Closed deferrals

(none yet — append ### YYYY-MM-DD — <slug> CLOSED (commit/PR) here when re-entered.)

2026-05-28 — plausible (Q4.7) recipe enrollment

  • What: Enroll plausible in cc-ci with parity health_check + ≥2 specific tests (per plan §4.3: "track a test event, query it back"). tests/plausible/recipe_meta.py + tests/plausible/functional/test_health_check.py are drafted (commit pending) but the e2e fails: services converge but the served app returns HTTP 500 from / for the full 600s HTTP_TIMEOUT window — config-class failure, not a deploy-timing issue.
  • Filed by: Builder, phase 2
  • Reason for deferral: The first deploy attempt set EXTRA_ENV={DISABLE_AUTH=true, DISABLE_REGISTRATION=true, SECRET_KEY_BASE=<64-char fixed>}. Stack converged 1/1 but the Phoenix app returned 500 the whole window. Likely missing required config (e.g. DATABASE_URL, MAILER vars, or a Phoenix bootstrap step). Diagnosing requires live container-log inspection
    • iterative env tuning — more debug time than fits a single autonomous loop pass.
  • Operator action to lift: Either (a) iterate on plausible's required env / debug live logs in an interactive session; OR (b) re-enroll plausible after the operator confirms a working env recipe.
  • Linked IDEA: —

2026-05-28 — lasuite-docs upload_conversion.py parity (.md/.docx upload + conversion)

  • What: Port recipe-info/lasuite-docs/tests/upload_conversion.py. The original uploads a .md and a .docx to POST /api/v1.0/documents/<id>/upload and asserts the y-provider / docspec conversion paths fire (.md → yjs; .docx → BlockNote → yjs).
  • Filed by: Builder, phase 2 (Q3.1 follow-up after the OIDC pieces closed)
  • Reason for deferral: Builder priority — the §4.3 create-a-doc floor is met by test_create_doc.py (closed in the entry above). Upload/conversion exercises a distinct subsystem (y-provider + docspec) and adds two binary fixtures + a multi-service-readiness wait. Defensible defer; lift when the operator wants the deeper coverage OR Phase-4 reviews.

2026-05-29 — immich recipe needs a pg_dump backup hook for reliable DB restore (P4)

  • What: immich's upstream recipe backs up the LIVE postgres data VOLUME via restic (backupbot.backup=true on database, no pg_dump hook), so a DB row does NOT survive abra app restore (diagnosed: seed→backup→drop→restore→row absent; app healthy). Real backup data-integrity (P4) requires a consistent SQL dump. Fix: add the drive/meet pattern to the immich recipe — pg_backup.sh swarm-config + labels backupbot.backup.pre-hook: "/pg_backup.sh backup" + backupbot.backup.volumes.postgres.path: "backup.sql" + backupbot.restore.post-hook: "/pg_backup.sh restore" (adapt POSTGRES_USER=postgres, POSTGRES_DB=immich). Via the recipe-create-pr flow (mirror immich on recipe-maintainers → branch → cc-ci full-suite GREEN on the PR incl. restore tier → Adversary cold-verify → operator merge), exactly like the parked Q3.2b lasuite-drive recipe-robustness PR.
  • Filed by: Builder, phase 2 (Q3.5 immich enrollment).
  • Reason for deferral: UPSTREAM recipe defect; the proper fix is a recipe PR (we maintain it), which is operator-merge-gated — not a cc-ci/test change. immich's other tiers (install/upgrade/ backup-artifact/restore-healthy/custom incl. §4.3 asset upload→readback→thumbnail) are GREEN.
  • Re-entry trigger: pick up as a recipe-PR unit (parallel to Q3.2b); OR Adversary §7.1 sign-off on the documented maximal subset if a recipe PR is out of scope for Phase-2 DONE.
  • Linked IDEA: —