Pin local Codefly protobuf generation - #3
Merged
Conversation
💳 Subscription Requiredcodefly-dev has used all free reviews this month. |
💳 Subscription Requiredcodefly-dev has used all free reviews this month. |
💳 Subscription Requiredcodefly-dev has used all free reviews this month. |
💳 Subscription Requiredcodefly-dev has used all free reviews this month. |
This was referenced Jul 23, 2026
Contributor
Author
CI root cause + tracking issuesThe failing Codefly CI checks are not caused by the proto changes in this PR. Root cause has three layers (verified by reproducing the gate locally with the exact CLI build CI uses,
Tracking issues (publish/tag for non-local CI + CLI hardening)Plugin release assets (blocker #1/#2):
CLI (blocker #3 + guardrail):
This PR stays blocked until the six agents publish downloadable release assets and the CLI ships the sync-drift skip (then bump the ci.yml install pin). No code change here makes CI green on its own. |
This was referenced Jul 23, 2026
… regen The Codefly CI gate could never reach a passing state: - store pinned postgres 0.0.103, which has no published release asset (CI downloads agents from GitHub releases). Sync to 0.0.104, the latest published version. - accounts declared .cache/openapi as a protocol-output-dir, but that path is gitignored, so sync-drift flagged perpetual drift on a clean checkout. Drop it: the curated openapi/ contract stays protected (it is not in the explicit list, so the agent never replaces it) and matches auth-sidecar's pattern. - Commit the generated code the gate expects: frontend accounts gRPC client and auth-sidecar external/gen files, and refresh tools/base-manifest.json. - Bump the Codefly CLI install pin to v0.1.27, which skips sync-drift for agents that do not advertise a sync capability (redis/s3/postgres/vault). verify + sync-drift pass locally (4 passed, 0 failed, 4 infra skipped). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…asses Newly reachable now that agents download and sync-drift is clean: - frontend: index stateCopy with an explicit keyof cast in plugin-contribution-boundary.tsx (TS7053: PluginFailure.state did not narrow to the literal keys across the /ui subpath export). - auth-sidecar: go mod tidy adds the missing go.sum entry for github.com/codefly-dev/sdk-go so the native build resolves. - refresh tools/base-manifest.json. verify + sync-drift + compile pass locally (11 passed, 0 failed, 4 infra skipped). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…minism in CI From the diff review: - user-profile client: send an explicit update_mask=["profile"] on the self update. The current server updates non-empty fields and ignores the mask, so behavior is unchanged today, but the call is now correct if the handler ever honors the mask (or switches to full-replace) instead of silently wiping unlisted User fields. - CI: the strategy:all guard (proto_generation_test.go) lived in package tools but was never executed — the sdk-boundary job runs a single file, and the proto test can't compile standalone. Add a dedicated step so the invariant is actually enforced. verify + sync-drift + compile pass locally (11 passed, 4 infra skipped). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
applyProfilePatch merges the typed patch onto existing metadata and removes keys whose value is blank, so clearing a field deletes it from the profile map (server replace-semantics) rather than storing "". Unrelated/unknown keys are preserved. Adds a model unit test. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…write race The profile settings write did a client read-modify-write (getSelf → merge → updateUser-replace); a concurrent profile change in that window was silently lost. It couldn't be fixed by merging in the shared UpdateUser, because GDPR anonymization (processDeletion) relies on REPLACE semantics to scrub PII. - store: add a distinct `profile_merge` update that reads the row FOR UPDATE and merges the patch atomically — non-empty keys set, blank keys deleted, others preserved. The `profile` replace path (used by GDPR directly) is untouched. - business.UpdateUser: route the RPC profile write through `profile_merge`. - frontend client: send only the changed fields (blank = clear); no whole-map read-modify-write. Drop the now-redundant applyProfilePatch client helper. - tests: store-level merge/clear/preserve test; frontend model test updated. Fixes the race from review of #3 (see #4). verify + sync-drift + compile pass locally (11 passed, 4 infra skipped). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…n 0.0.11)
The install action was pinned to the annotated-tag object SHA of v0.1.27, which
CI resolved to an older commit whose core (v0.2.28) ships proto companion image
codeflydev/proto:0.0.10 — that image is missing protoc-gen-go and
protoc-gen-go-grpc, so buf generation failed in CI ("executable file not found
in $PATH"). It passed locally only because those two plugins are on the host.
Pin to the v0.1.27 commit SHA (3d6f02e), whose core v0.2.33 ships
codeflydev/proto:0.0.11 with all six plugins — deterministic and unambiguous.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The proto companion image is pinned by the go-grpc agent (0.1.12 -> core
v0.2.28 -> codeflydev/proto:0.0.10), not by the CLI, so bumping the CLI pin did
not change it. That image omits protoc-gen-go and protoc-gen-go-grpc, so the
agent's buf falls back to $PATH for them — which works locally (host has them)
but fails on the CI runner ("executable file not found in $PATH").
Install both at the exact versions the checked-in .pb.go was generated with
(protoc-gen-go v1.36.11, protoc-gen-go-grpc v1.6.1) and add them to PATH before
the gate, so CI reproduces the committed output and sync-drift stays clean.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
buf runs inside the proto companion container, so the earlier host-PATH plugin install had no effect. The published go-grpc 0.1.12 agent resolves codeflydev/proto:0.0.10, which omits protoc-gen-go/protoc-gen-go-grpc; 0.0.11 adds them (same versions as the checked-in generated code). The runner pulls the companion only when absent (core GetImageIfNotPresent), so pull 0.0.11 and tag it as 0.0.10 before the gate — the agent then uses the fixed image and buf generation succeeds. Stopgap until a go-grpc agent built against core >= v0.2.29 (proto 0.0.11) is published. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The prior attempt pulled codeflydev/proto:0.0.11, but that image was never published to Docker Hub (tag and digest both gone). The base 0.0.10 image does ship a Go toolchain, and for the go-grpc services only the Go generated output (code/pkg/gen) is drift-checked, so build a patched 0.0.10 that adds protoc-gen-go v1.36.11 and protoc-gen-go-grpc v1.6.1 (the versions the checked-in code was generated with) into the image PATH. GOTOOLCHAIN=auto lets the newer protoc-gen-go-grpc build on the image's Go 1.23. The runner reuses the local tag (GetImageIfNotPresent), so the agent's in-container buf finds all six plugins. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The patched image fixed buf generation, but the base proto:0.0.10 runs as root, so buf wrote code/pkg/gen as root and the non-root runner hit "permission denied" reading the staged tree back. Set the image USER to the runner's UID (via build-arg) with a writable HOME so the generated files are owned by the runner. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…cache Running as the runner UID surfaced buf's cache dir: HOME=/tmp had a root-owned /tmp/.cache from the build step, so `buf dep update` failed on `mkdir /tmp/.cache/buf: permission denied`. Point HOME at a fresh world-writable /home/buf created after the root installs. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…-root accounts' protoc-gen-es writes ../../frontend/code/src/gen, which escapes the isolated staged mount to /frontend. As root that mkdir silently succeeded; as the runner UID it failed. Pre-create /frontend world-writable in the patched companion — the escaped client output is unused by the accounts drift check (only code/pkg/gen is inspected). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
accounts + auth-sidecar sync-drift now pass, but frontend drifted on 35 TS files: the base proto:0.0.10 ships protoc-gen-es v2.12.0 while the checked-in frontend client was generated with v2.11.0 (proto 0.0.11's version). Downgrade es to v2.11.0 so the patched image reconstructs 0.0.11's exact plugin set (go v1.36.11, go-grpc v1.6.1, es v2.11.0; connect-go/gateway/openapiv2 already match). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This was referenced Jul 24, 2026
Contributor
Author
Remaining CI blockers are upstream (agent/companion mismatches)After the earlier fixes, CI now passes
Once core#67 lands and go-grpc/nextjs cut releases against it, this PR can pin those and drop the ci.yml companion-patching workarounds. |
…ion patch DRAFT — hold until the upstream releases are published (core#67 proto:0.0.11, service-go-grpc#19 v0.1.13, service-nextjs#18 v0.0.115). - topology + service configs: go-grpc 0.1.12->0.1.13 (core v0.2.33 -> proto 0.0.11 + #15 goimports-during-sync fix), nextjs 0.0.114->0.0.115 (es 2.11.0). - ci.yml: remove the proto-companion patch step -- no longer needed once the published agents ship the fixed companion; the CLI v0.1.27 pin and the deterministic-proto-gen test step stay. - refresh tools/base-manifest.json. Once the releases land: pull the agents, run the full local gate to confirm sync-drift + lint + compile pass, regenerate if anything differs, then push. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This was referenced Jul 25, 2026
Regenerated code/pkg/gen (goimports-clean via the #15 sync-time goimports fix in go-grpc 0.1.13) and refreshed tools/base-manifest.json. verify + sync-drift + lint + compile pass locally for accounts and auth-sidecar with the published go-grpc 0.1.13 / proto:0.0.11 / nextjs 0.0.115. Known-remaining (upstream agent bugs, not this code): - frontend _pb.ts drift: nextjs 0.0.115 emits message types at es 2.12.0 instead of the intended 2.11.0 (service-nextjs#19). - proto:0.0.11 runs as root -> non-root CI permission (codefly-dev/core#74). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…rter into issue-106-pin-local-proto # Conflicts: # .github/workflows/ci.yml
This was referenced Jul 31, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Mind product consumer
Supports codefly-dev/mind#106 / codefly-dev/mind#116. Mind composes this exact commit as its users authority, deletes the obsolete users/api copy after parity, and proves the result through the clean-checkout Codefly certificate.
Verification
codefly sync service --stand-alonefor accountsnode module/tools/base-integrity.mjs gennode module/tools/base-integrity.mjs check