Skip to content

ENG-1984: Fetch the organization key lazily, only when an encrypted artifact is present#3841

Open
mitchell-as wants to merge 2 commits into
version/0-48-1-RC3from
mitchell/eng-1984
Open

ENG-1984: Fetch the organization key lazily, only when an encrypted artifact is present#3841
mitchell-as wants to merge 2 commits into
version/0-48-1-RC3from
mitchell/eng-1984

Conversation

@mitchell-as

@mitchell-as mitchell-as commented Jul 14, 2026

Copy link
Copy Markdown
Collaborator

ENG-1984: Fetch the organization key lazily, only when an encrypted artifact is present

Part of the private ingredient work (ENG-1563). Checking out a project with no encrypted ingredients still printed a spurious "Could not fetch the organization key" warning whenever a key service was configured.

The key is now fetched only when the runtime actually hits an encrypted artifact, rather than up front — so projects with no private ingredients never contact the key service (no warning, no delay). The existing end-of-run notice still reports anything skipped because the key was unavailable.

Base branch: targets version/0-48-1-RC3.

🤖 Generated with Claude Code

…rtifact is present

Checking out a project with no encrypted private ingredients printed a spurious
"Could not fetch the organization key" warning whenever a key service was
configured, because the key was fetched eagerly regardless of whether the runtime
had anything to decrypt.

The runtime now receives a key-fetch callback (WithDecryptionKey) instead of the
key bytes and invokes it only when it actually encounters an encrypted artifact
during unpack. A runtime with no private artifacts never contacts the key service
— no spurious warning and no fetch latency. The premature warning is removed; the
existing end-of-run notice (skipReporter) already reports any artifacts skipped
because the key was unavailable, which is the only case worth surfacing.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR changes runtime installation to fetch the organization decryption key lazily, only when an encrypted artifact is actually encountered, avoiding unnecessary key-service calls (and warnings) for projects with no private ingredients.

Changes:

  • Replace the eager org-key material on runtime.Opts with a lazy OrgKey() fetch function.
  • Decrypt logic now requests the org key only after detecting an encrypted payload, and skips decryption if the key is unavailable.
  • Update tests to use the new lazy key-fetch API and add coverage for key-fetch errors.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File Description
pkg/runtime/setup.go Switches decryption flow to call a lazy org-key fetcher only when encrypted payloads are detected.
pkg/runtime/options.go Updates WithDecryptionKey to accept a lazy key-fetch function instead of key bytes/ID.
pkg/runtime/decrypt_test.go Adapts tests to the lazy key-fetch interface and adds a “fetch error skips” test.
internal/runbits/runtime/runtime.go Stops fetching org key up front; supplies a lazy org-key fetch closure to runtime setup.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread internal/runbits/runtime/runtime.go
…ts notice

When private artifacts are skipped because the organization key could not be
obtained, the end-of-run notice now includes the underlying reason (e.g. the
connection or certificate error) instead of leaving it in the debug log. The
fetch is memoized, so retrieving the reason costs no additional key-service call.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@mitchell-as mitchell-as requested a review from MDrakos July 15, 2026 16:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants