[DEV-1656] Support V2 projection engine on create

[w1am]

Adds an EngineVersion option to CreateProjectionOptions so callers can select the V2 projection engine when creating a projection. Defaults to V1 when unset.

Selecting V2 together with TrackEmittedStreams is rejected up front, since V2 does not support emitted-stream tracking.

Linear: DEV-1656

[linear]

DEV-1656 Go | Support projection v2 engine

[qodo-code-review]

Review Summary by Qodo

Support V2 projection engine on create

✨ Enhancement

Walkthroughs

Description

• Add EngineVersion option to CreateProjectionOptions for V2 engine selection
• Validate that V2 engine rejects TrackEmittedStreams option
• Update protobuf definitions to include engine_version field
• Add tests for V2 engine creation and validation

Diagram

flowchart LR
  A["CreateProjectionOptions"] -->|"adds EngineVersion field"| B["ProjectionEngineVersion enum"]
  B -->|"V1, V2, Unspecified"| C["Create method validation"]
  C -->|"rejects V2 + TrackEmittedStreams"| D["Error handling"]
  C -->|"passes to gRPC"| E["Protobuf CreateReq_Options"]
  E -->|"includes engine_version"| F["Server processing"]

Loading

File Changes

1. kurrentdb/projection_options.go ✨ Enhancement +22/-0

Add ProjectionEngineVersion enum and option

• Define ProjectionEngineVersion type with three constants: Unspecified (0), V1 (1), and V2
 (2)
• Add comprehensive documentation for V2 engine limitations (no TrackEmittedStreams, bi-state
 projections, or live outputState)
• Add EngineVersion field to CreateProjectionOptions struct with default behavior documentation

kurrentdb/projection_options.go

---

2. kurrentdb/projection_client.go ✨ Enhancement +8/-1

Validate V2 engine and pass to gRPC

• Import fmt package for error formatting
• Add validation in Create method to reject V2 engine when TrackEmittedStreams is enabled
• Pass EngineVersion value to protobuf CreateReq_Options as int32

kurrentdb/projection_client.go

---

3. protos/kurrentdb/protocols/v1/projections.proto ⚙️ Configuration changes +1/-0

Add engine_version field to protobuf

• Add int32 engine_version field (field number 5) to CreateReq.Options message
• Include inline comment documenting that 0 or 1 = v1 (default), 2 = v2

protos/kurrentdb/protocols/v1/projections.proto

---

View more (2)

4. protos/kurrentdb/protocols/v1/projections/projections.pb.go Dependencies +12/-3

Generate protobuf code for engine_version

• Add EngineVersion int32 field to CreateReq_Options struct with protobuf annotations
• Generate getter method GetEngineVersion() returning int32 with default value 0
• Update protobuf file descriptor raw string to reflect new field in message definition

protos/kurrentdb/protocols/v1/projections/projections.pb.go

---

5. test/projection_test.go 🧪 Tests +25/-0

Add V2 engine creation and validation tests

• Add TestCreateProjectionV2Engine test to verify successful V2 engine projection creation
• Add TestCreateProjectionV2EngineRejectsTrackEmittedStreams test to verify validation error when
 combining V2 with TrackEmittedStreams

test/projection_test.go

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. Goimports CI will fail ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

kurrentdb/projection_client.go’s import block mixes stdlib and third-party imports and splits
third-party imports into multiple groups, which goimports will rewrite. The CI workflow enforces
goimports -d ./, so this will fail the formatting check and block merge.

Code

kurrentdb/projection_client.go[R3-9]

import (
	"context"
	"errors"
+	"fmt"
	"github.com/kurrent-io/KurrentDB-Client-Go/protos/kurrentdb/protocols/v1/projections"
	"github.com/kurrent-io/KurrentDB-Client-Go/protos/kurrentdb/protocols/v1/shared"
	"io"

Evidence

The workflow explicitly fails if goimports -d ./ produces any diff output. The modified import
block in projection_client.go is not in goimports’ canonical grouped/sorted form (stdlib imports
should be grouped together and separated from third-party imports).

kurrentdb/projection_client.go[3-14]
.github/workflows/go.yml[66-76]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`kurrentdb/projection_client.go` imports are not in `goimports`-canonical order/grouping, and CI enforces `goimports -d ./`.

### Issue Context
The workflow’s formatting step will fail if any file changes under goimports.

### Fix Focus Areas
- kurrentdb/projection_client.go[3-14]
- .github/workflows/go.yml[66-76]

### Expected change
Reorder/group imports so stdlib imports are together (e.g., context/errors/fmt/io), followed by a blank line, then all third-party imports (github.com/* and google.golang.org/* in the same group).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Unvalidated EngineVersion values 🐞 Bug ☼ Reliability

Description

ProjectionClient.Create forwards opts.EngineVersion to the wire as an int32 without validating it
is one of the documented values (0/1/2), so callers can pass an invalid value and get a server-side
rejection that isn’t caught early. Only the specific V2+TrackEmittedStreams combination is checked
client-side.

Code

kurrentdb/projection_client.go[R69-73]

	_, err = projClient.Create(ctx, &projections.CreateReq{
		Options: &projections.CreateReq_Options{
-			Query: query,
+			Query:         query,
+			EngineVersion: int32(opts.EngineVersion),
			Mode: &projections.CreateReq_Options_Continuous_{

Evidence

The proto documents engine_version as 0/1=v1 and 2=v2, and the client exposes only those constants,
but Create sends any int32 value the caller sets. That means invalid values won’t be rejected until
the RPC hits the server (or may be misinterpreted), making failures harder to diagnose.

kurrentdb/projection_client.go[46-83]
kurrentdb/projection_options.go[5-38]
protos/kurrentdb/protocols/v1/projections.proto[22-33]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`ProjectionClient.Create` sends `EngineVersion` as an `int32` without validating it is within the supported/documented set.

### Issue Context
The API exposes `ProjectionEngineVersion` constants (0/1/2) and the proto comment documents those as valid. Without validation, callers can pass arbitrary values and only discover the problem via server-side errors.

### Fix Focus Areas
- kurrentdb/projection_client.go[46-83]
- kurrentdb/projection_options.go[5-38]
- protos/kurrentdb/protocols/v1/projections.proto[22-33]

### Suggested fix
Add a small validation block in `ProjectionClient.Create` (after `opts.setDefaults()`), e.g. a `switch opts.EngineVersion` allowing `Unspecified`, `V1`, `V2` and returning a clear error for anything else (optionally at least reject negative values if you want some forward-compatibility).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[github-actions]

@w1am 👉 Created pull request targeting release/v1.2: #44