Skip to content

Define Service warm-delivery contract - #119

Merged
MFS-code merged 8 commits into
mainfrom
feat/service-warm-delivery-contract
Aug 6, 2026
Merged

MFS-code merged 8 commits into
mainfrom
feat/service-warm-delivery-contract

Conversation

@MFS-code

@MFS-code MFS-code commented Aug 6, 2026 •

Copy link
Copy Markdown
Owner

Summary

  • add an explicit Service runtime delivery capability and immutable AgentRun delivery snapshot
  • resolve sparse Service invocations through the existing admission path without changing Task semantics
  • define the versioned HTTP request, Pod identity binding, HMAC challenge-response, result response, and lifecycle contract
  • keep delivered invocation snapshots Pending and out of the Pod path until the delivery controller lands, while standing Service runs remain available

Merge sequencing

This is the contract/API half of warm delivery. PR #120 activates the delivery-aware controller path. If #119 is deployed alone, delivered invocation snapshots fail closed in Pending and never spawn cold Pods.

Complete referenced runs intentionally bypass sparse invocation admission. They do not enter Service recast accounting without a controller owner reference; #120 also verifies that ownership and excludes delivery snapshots from standing-run selection.

Test plan

  • make test
  • make verify

Closes #117

Let Service Agents opt into sparse referenced work while keeping delivered audit records distinct from standing Pod-owning runs. Freeze the HTTP request and result semantics so runtime and controller implementations can proceed independently.
@vercel

vercel Bot commented Aug 6, 2026 •

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
kontext Ready Ready Preview Aug 6, 2026 6:30pm
kontext-docs Ready Ready Preview Aug 6, 2026 6:30pm

Request Review

@greptile-apps

greptile-apps Bot commented Aug 6, 2026 •

Copy link
Copy Markdown

Greptile Summary

This PR defines the API and runtime contract for warm delivery while deliberately leaving delivery execution to the stacked controller change.

  • Adds Service runtime delivery capability and immutable AgentRun delivery snapshots.
  • Extends sparse admission resolution to warm-delivery Service invocations.
  • Keeps delivered runs Pending and out of the dedicated Pod path until the delivery controller is available.
  • Documents the versioned HTTP protocol, Pod identity binding, response authentication, and lifecycle semantics.

Confidence Score: 5/5

The PR appears safe to merge, with no blocking failure remaining in the previously reported areas.

No blocking failure remains.

Important Files Changed

Filename Overview
internal/runfactory/runfactory.go Extends sparse resolution to delivery-enabled Services, snapshots the delivery marker, and rejects names reserved for standing runs.
internal/controller/agentrun_controller.go Uses spec.delivery as the lifecycle discriminator so delivered runs fail closed while standing Service runs continue through Pod reconciliation.
api/v1alpha1/agent_types.go Adds the Service-only runtime delivery capability and validates its relationship with the Service invocation template.
api/v1alpha1/agentrun_types.go Adds an immutable delivery snapshot with validation tying its port to the resolved runtime capability.
pkg/delivery/v1alpha1/types.go Defines the versioned warm-delivery request and target identity envelope.
SPEC.md Documents the warm-delivery wire protocol, authenticated result response, identity checks, and lifecycle contract.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Sparse referenced AgentRun] --> B[Invocation admission]
  B --> C{Referenced Agent mode}
  C -->|Task| D[Resolved immutable Task snapshot]
  C -->|Delivery-enabled Service| E[Resolved snapshot with spec.delivery]
  D --> F[AgentRun reconciler]
  F --> G[Create dedicated Pod]
  E --> H[AgentRun reconciler]
  H --> I[Remain Pending without dedicated Pod]
  J[Service controller] --> K[Standing AgentRun without spec.delivery]
  K --> F
Loading

Reviews (6): Last reviewed commit: "Allow standing Service runs to create Po..." | Re-trigger Greptile

Comment thread internal/runfactory/runfactory.go
Service Agents without warm delivery now fail with DeliveryDisabled, so retain WrongMode coverage with a Scheduled Agent and assert both admission classes explicitly.
Prevent admitted delivery records from occupying the canonical names the Service controller needs for initial creation and later recasts.
Comment thread internal/runfactory/runfactory.go
@MFS-code MFS-code mentioned this pull request Aug 6, 2026
2 tasks done
Fail closed while the warm-delivery controller is absent so the contract can land without accidentally executing delivered work in a cold Pod.
Carry the verified Pod identity in the strict request contract and require hostname matching so a reassigned Pod IP cannot silently accept work for another runtime.
Define a per-Pod secret challenge-response so the controller can verify that a result came from the selected runtime without transmitting its credential over Pod HTTP.
Comment thread internal/controller/agentrun_controller.go Outdated
Keep only delivered invocation snapshots out of the Pod path so the standing runtime remains available while the controller implementation is stacked.
@MFS-code
MFS-code merged commit a1ac576 into main Aug 6, 2026
5 checks passed

This branch was successfully deployed

2 active deployments
Preview – kontext-docs — 119ee340 Deployed Aug 6, 2026 by vercel[bot]
Preview – kontext — 119ee340 Deployed Aug 6, 2026 by vercel[bot]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Spec + API: warm delivery contract for Service-mode agents

1 participant