Release

[omkar273]

Summary by CodeRabbit

• Bug Fixes

  • Safer customer listing: large result sets fetched in paginated batches.

• New Features

  • Helm chart v1.0.0 (GA) with full templates, values and packaging.
  • Multi-architecture image publishing and enhanced CI/CD publish/deploy workflows.
  • New provisioning script for streamlined local (kind) and production installs.
  • Subscription "auto-invoice threshold": API field, scheduled billing, and end-to-end tests.

• Documentation

  • Extensive Helm/operator docs: architecture, quickstarts, backups, secrets, migration, troubleshooting, and production readiness.

[coderabbitai]

Actionable comments posted: 5

🧹 Nitpick comments (1)

internal/api/dto/subscription_test.go (1)

86-124: ⚡ Quick win

Prefer a table-driven shape for the multi-scenario threshold test.

This test covers multiple scenarios well, but converting it to a table-driven loop would align with the test convention used in this repo and reduce repetition.

As per coding guidelines "**/*_test.go: Use table-driven tests to test multiple scenarios in a single test function".

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@internal/api/dto/subscription_test.go` around lines 86 - 124, Replace the
multiple t.Run blocks in
TestCreateSubscriptionRequestValidate_AutoInvoiceThreshold with a single
table-driven loop: define a slice of test cases (name, optional
AutoInvoiceThreshold value, expectError bool, expectMessage string) then iterate
calling t.Run(tc.name, func(t *testing.T){ set req :=
baseCreateSubscriptionRequest(); assign tc.AutoInvoiceThreshold to
req.AutoInvoiceThreshold when non-nil; call req.Validate(); assert error
presence matches expectError and, when expectMessage is set, assert
strings.Contains(strings.ToLower(err.Error()), tc.expectMessage) }); keep
references to TestCreateSubscriptionRequestValidate_AutoInvoiceThreshold,
baseCreateSubscriptionRequest, req.Validate, and the AutoInvoiceThreshold field
so the behavior and assertions (including the negative case checking for
"auto_invoice_threshold") remain identical.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@ent/schema/subscription.go`:
- Around line 205-211: Add a database index for the new auto_invoice_threshold
field to support efficient threshold-based billing scans: update the
Subscription schema where field.Other("auto_invoice_threshold",
decimal.Decimal{}) is defined and add an Index that includes
"auto_invoice_threshold" (create a descriptive name like
idx_subscription_auto_invoice_threshold). If you expect queries to also filter
by status/tenant during cron scans, add a composite index on
("auto_invoice_threshold", "status") or ("auto_invoice_threshold", "tenant_id")
as appropriate to your query patterns; ensure the index is declared using the
schema's Index(...) builder so Ent will generate the migration.

In `@internal/repository/ent/subscription.go`:
- Around line 1165-1211: GetSubscriptionsWithAutoInvoiceThreshold is missing the
subscription type filter, causing inherited/parent subscriptions to be returned;
update the Ent query in GetSubscriptionsWithAutoInvoiceThreshold to include
subscription.SubscriptionTypeEQ(types.SubscriptionTypeStandalone) in the
Where(...) clause (alongside the existing
TenantID/EnvironmentID/Status/SubscriptionStatus/AutoInvoiceThreshold filters)
so the repository matches the in-memory store behavior.

In `@internal/service/subscription_threshold_billing_test.go`:
- Around line 272-314: The test inserts follow-up events at
t1.Add(1*time.Minute) which can be in the future relative to the immediate
second call to ProcessAutoInvoiceThresholdBilling, so the second run sees an
empty window; change the follow-up insert timestamp to be slightly before the
second run (e.g. t1.Add(-1*time.Minute) or t1.Add(-1*time.Second)) so the events
are inside the new-period window when calling ProcessAutoInvoiceThresholdBilling
again; update the call site that uses s.insertEvents(500, t1.Add(1*time.Minute))
in TestThresholdBilling_PeriodAdvanceResetsUsageWindow to use a past timestamp
(referencing s.insertEvents and ProcessAutoInvoiceThresholdBilling) so the
second invocation actually evaluates the new period's usage.

In `@internal/service/subscription.go`:
- Around line 7721-7727: The call to invoiceService.CreateSubscriptionInvoice is
reusing the period-end renewal path (ReferencePointPeriodEnd and
types.InvoiceFlowRenewal) for a mid-period threshold hit, which causes
recurring/advance items to be invoiced incorrectly; change this to a dedicated
threshold-invoice flow by invoking CreateSubscriptionInvoice with a reference
point and flow that represent threshold billing (e.g., a new
ReferencePointThreshold or ReferencePointNow and a new/explicit
types.InvoiceFlowThreshold) or add a boolean/flag to CreateSubscriptionInvoice
to restrict invoicing to accrued usage since sub.CurrentPeriodStart only; update
any callers and enum values (ReferencePointPeriodEnd, types.InvoiceFlowRenewal)
accordingly so threshold hits do not trigger advance/recurring charges.
- Around line 7719-7736: The code ignores the updated subscription returned by
invoiceService.CreateSubscriptionInvoice and instead persists the original sub,
which can overwrite status/payment changes; capture the returned subscription
(replace the blank identifier "_" with a variable like updatedSub), use
updatedSub when advancing CurrentPeriodStart (set updatedSub.CurrentPeriodStart
= effectiveTime) and pass updatedSub to s.SubRepo.Update(ctx, updatedSub) so the
transaction persists the latest subscription state from
CreateSubscriptionInvoice.

---

Nitpick comments:
In `@internal/api/dto/subscription_test.go`:
- Around line 86-124: Replace the multiple t.Run blocks in
TestCreateSubscriptionRequestValidate_AutoInvoiceThreshold with a single
table-driven loop: define a slice of test cases (name, optional
AutoInvoiceThreshold value, expectError bool, expectMessage string) then iterate
calling t.Run(tc.name, func(t *testing.T){ set req :=
baseCreateSubscriptionRequest(); assign tc.AutoInvoiceThreshold to
req.AutoInvoiceThreshold when non-nil; call req.Validate(); assert error
presence matches expectError and, when expectMessage is set, assert
strings.Contains(strings.ToLower(err.Error()), tc.expectMessage) }); keep
references to TestCreateSubscriptionRequestValidate_AutoInvoiceThreshold,
baseCreateSubscriptionRequest, req.Validate, and the AutoInvoiceThreshold field
so the behavior and assertions (including the negative case checking for
"auto_invoice_threshold") remain identical.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 1b0e6406-3c80-43f4-b313-736ff8df22fb

📥 Commits

Reviewing files that changed from the base of the PR and between e65e1c3 and ec564b7.

📒 Files selected for processing (37)

• docs/superpowers/specs/2026-05-07-trial-start-invoice-design.md
• ent/migrate/schema.go
• ent/mutation.go
• ent/schema/subscription.go
• ent/subscription.go
• ent/subscription/subscription.go
• ent/subscription/where.go
• ent/subscription_create.go
• ent/subscription_update.go
• internal/api/dto/subscription.go
• internal/api/dto/subscription_test.go
• internal/domain/subscription/model.go
• internal/domain/subscription/model_test.go
• internal/domain/subscription/repository.go
• internal/interfaces/service.go
• internal/repository/ent/subscription.go
• internal/service/line_item_proration_test.go
• internal/service/price_test.go
• internal/service/subscription.go
• internal/service/subscription_line_item_test.go
• internal/service/subscription_modification.go
• internal/service/subscription_modification_test.go
• internal/service/subscription_test.go
• internal/service/subscription_threshold_billing_test.go
• internal/service/subscription_trial_payment_matrix_test.go
• internal/service/subscription_trial_test.go
• internal/temporal/activities/cron/subscription_activities.go
• internal/temporal/models/cron.go
• internal/temporal/registration.go
• internal/temporal/service/schedules.go
• internal/temporal/workflows/cron/auto_invoice_threshold_billing_workflow.go
• internal/testutil/base_service_suite.go
• internal/testutil/inmemory_subscription_store.go
• internal/testutil/inmemory_subscription_store_test.go
• internal/types/invoice.go
• internal/types/schedule.go
• internal/types/schedule_test.go

💤 Files with no reviewable changes (1)

• docs/superpowers/specs/2026-05-07-trial-start-invoice-design.md

✅ Files skipped from review due to trivial changes (7)

• internal/service/subscription_trial_payment_matrix_test.go
• ent/subscription/subscription.go
• ent/subscription_update.go
• ent/subscription.go
• ent/subscription/where.go
• ent/migrate/schema.go
• ent/mutation.go

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Add an index for threshold-based billing scans.

The new auto_invoice_threshold field is introduced for recurring billing checks, but there’s no index to support threshold filtering. This can degrade cron performance as subscriptions grow.

💡 Suggested schema index addition

 func (Subscription) Indexes() []ent.Index {
 	return []ent.Index{
 		// Common query patterns from repository layer
 		index.Fields("tenant_id", "environment_id", "customer_id", "status").
 			Annotations(entsql.IndexWhere("status = 'published'")),
 		index.Fields("tenant_id", "environment_id", "plan_id", "status"),
 		index.Fields("tenant_id", "environment_id", "subscription_status", "status"),
 		// For billing period updates
 		index.Fields("tenant_id", "environment_id", "current_period_end", "subscription_status", "status"),
+		// For auto-invoice-threshold candidate scans
+		index.Fields("tenant_id", "environment_id", "auto_invoice_threshold", "subscription_status", "status").
+			Annotations(entsql.IndexWhere("auto_invoice_threshold IS NOT NULL AND auto_invoice_threshold > 0 AND status = 'published'")),
 	}
 }

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	field.Other("auto_invoice_threshold", decimal.Decimal{}).
	Optional().
	Nillable().
	SchemaType(map[string]string{
	"postgres": "decimal(20,6)",
	}).
	Comment("Threshold usage amount (in subscription currency) that triggers an intermediate invoice. Overrides plan-level threshold when set."),
	func (Subscription) Indexes() []ent.Index {
	return []ent.Index{
	// Common query patterns from repository layer
	index.Fields("tenant_id", "environment_id", "customer_id", "status").
	Annotations(entsql.IndexWhere("status = 'published'")),
	index.Fields("tenant_id", "environment_id", "plan_id", "status"),
	index.Fields("tenant_id", "environment_id", "subscription_status", "status"),
	// For billing period updates
	index.Fields("tenant_id", "environment_id", "current_period_end", "subscription_status", "status"),
	// For auto-invoice-threshold candidate scans
	index.Fields("tenant_id", "environment_id", "auto_invoice_threshold", "subscription_status", "status").
	Annotations(entsql.IndexWhere("auto_invoice_threshold IS NOT NULL AND auto_invoice_threshold > 0 AND status = 'published'")),
	}
	}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@ent/schema/subscription.go` around lines 205 - 211, Add a database index for
the new auto_invoice_threshold field to support efficient threshold-based
billing scans: update the Subscription schema where
field.Other("auto_invoice_threshold", decimal.Decimal{}) is defined and add an
Index that includes "auto_invoice_threshold" (create a descriptive name like
idx_subscription_auto_invoice_threshold). If you expect queries to also filter
by status/tenant during cron scans, add a composite index on
("auto_invoice_threshold", "status") or ("auto_invoice_threshold", "tenant_id")
as appropriate to your query patterns; ensure the index is declared using the
schema's Index(...) builder so Ent will generate the migration.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Missing subscription type filter in Ent repository.

The in-memory test store implementation at internal/testutil/inmemory_subscription_store.go:553 filters for SubscriptionTypeStandalone:

if sub.SubscriptionType != types.SubscriptionTypeStandalone || sub.Status != types.StatusPublished {
    continue
}

However, this Ent repository implementation does not include a similar filter. This means the Ent implementation would return parent/inherited subscriptions with thresholds, while the test store would not—leading to test/production behavioral drift.

🔧 Proposed fix to add subscription type filter

 	subs, err := r.client.Reader(ctx).Subscription.Query().
 		Where(
 			subscription.TenantID(tenantID),
 			subscription.EnvironmentID(envID),
 			subscription.Status(string(types.StatusPublished)),
 			subscription.SubscriptionStatusEQ(types.SubscriptionStatusActive),
+			subscription.SubscriptionTypeEQ(types.SubscriptionTypeStandalone),
 			subscription.AutoInvoiceThresholdNotNil(),
 			subscription.AutoInvoiceThresholdGT(decimal.Zero),
 		).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@internal/repository/ent/subscription.go` around lines 1165 - 1211,
GetSubscriptionsWithAutoInvoiceThreshold is missing the subscription type
filter, causing inherited/parent subscriptions to be returned; update the Ent
query in GetSubscriptionsWithAutoInvoiceThreshold to include
subscription.SubscriptionTypeEQ(types.SubscriptionTypeStandalone) in the
Where(...) clause (alongside the existing
TenantID/EnvironmentID/Status/SubscriptionStatus/AutoInvoiceThreshold filters)
so the repository matches the in-memory store behavior.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

The second run is exercising an empty window, not the new-period window.

Lines 288-290 insert the follow-up events at t1.Add(1 * time.Minute), but the second ProcessAutoInvoiceThresholdBilling call runs immediately afterward. In practice those events are usually still in the future, so this test passes because the second run sees no current-period usage, not because the first period was correctly cut off.

Suggested fix

-	// Period 2: only 500 events -> $5.00, below the $10 threshold.
-	// Timestamps are 1 minute after T1 to ensure they fall inside the new window.
-	s.insertEvents(500, t1.Add(1*time.Minute))
+	// Period 2: only 500 events -> $5.00, below the $10 threshold.
+	// Use a timestamp after T1 but not in the future relative to the second run.
+	ts := time.Now().UTC()
+	if ts.Before(t1) {
+		ts = t1
+	}
+	s.insertEvents(500, ts)

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	func (s *SubscriptionThresholdBillingTestSuite) TestThresholdBilling_PeriodAdvanceResetsUsageWindow() {
	ctx := s.GetContext()
	// Period 1: 1001 events -> $10.01, crosses threshold.
	// Timestamp 1 hour before now, inside the original period (now-7d .. now).
	s.insertEvents(1001, s.testData.now.Add(-1*time.Hour))
	result1, err := s.service.ProcessAutoInvoiceThresholdBilling(ctx)
	s.NoError(err)
	s.Equal(1, result1.TotalInvoiced, "first run should invoice subA")
	// Record the new CurrentPeriodStart (T1 approx time of first run).
	reloadedAfterFirst, err := s.GetStores().SubscriptionRepo.Get(ctx, s.testData.subA.ID)
	s.NoError(err)
	t1 := reloadedAfterFirst.CurrentPeriodStart
	// Period 2: only 500 events -> $5.00, below the $10 threshold.
	// Timestamps are 1 minute after T1 to ensure they fall inside the new window.
	s.insertEvents(500, t1.Add(1*time.Minute))
	result2, err := s.service.ProcessAutoInvoiceThresholdBilling(ctx)
	s.NoError(err)
	s.Require().NotNil(result2)
	// Second run must skip subA: $5 usage < $10 threshold.
	s.Equal(1, result2.TotalChecked)
	s.Equal(0, result2.TotalInvoiced)
	s.Equal(1, result2.TotalSkipped)
	s.Equal(0, result2.TotalFailed)
	// Still exactly one invoice in the store (the one from the first run).
	filter := types.NewNoLimitInvoiceFilter()
	filter.SubscriptionID = s.testData.subA.ID
	invoices, err := s.GetStores().InvoiceRepo.List(ctx, filter)
	s.NoError(err)
	s.Len(invoices, 1, "no second invoice should have been created")
	// CurrentPeriodStart must not have moved again.
	reloadedAfterSecond, err := s.GetStores().SubscriptionRepo.Get(ctx, s.testData.subA.ID)
	s.NoError(err)
	s.True(reloadedAfterSecond.CurrentPeriodStart.Equal(t1),
	"CurrentPeriodStart should remain at T1 after the skipped second run")
	}
	func (s *SubscriptionThresholdBillingTestSuite) TestThresholdBilling_PeriodAdvanceResetsUsageWindow() {
	ctx := s.GetContext()
	// Period 1: 1001 events -> $10.01, crosses threshold.
	// Timestamp 1 hour before now, inside the original period (now-7d .. now).
	s.insertEvents(1001, s.testData.now.Add(-1*time.Hour))
	result1, err := s.service.ProcessAutoInvoiceThresholdBilling(ctx)
	s.NoError(err)
	s.Equal(1, result1.TotalInvoiced, "first run should invoice subA")
	// Record the new CurrentPeriodStart (T1 approx time of first run).
	reloadedAfterFirst, err := s.GetStores().SubscriptionRepo.Get(ctx, s.testData.subA.ID)
	s.NoError(err)
	t1 := reloadedAfterFirst.CurrentPeriodStart
	// Period 2: only 500 events -> $5.00, below the $10 threshold.
	// Use a timestamp after T1 but not in the future relative to the second run.
	ts := time.Now().UTC()
	if ts.Before(t1) {
	ts = t1
	}
	s.insertEvents(500, ts)
	result2, err := s.service.ProcessAutoInvoiceThresholdBilling(ctx)
	s.NoError(err)
	s.Require().NotNil(result2)
	// Second run must skip subA: $5 usage < $10 threshold.
	s.Equal(1, result2.TotalChecked)
	s.Equal(0, result2.TotalInvoiced)
	s.Equal(1, result2.TotalSkipped)
	s.Equal(0, result2.TotalFailed)
	// Still exactly one invoice in the store (the one from the first run).
	filter := types.NewNoLimitInvoiceFilter()
	filter.SubscriptionID = s.testData.subA.ID
	invoices, err := s.GetStores().InvoiceRepo.List(ctx, filter)
	s.NoError(err)
	s.Len(invoices, 1, "no second invoice should have been created")
	// CurrentPeriodStart must not have moved again.
	reloadedAfterSecond, err := s.GetStores().SubscriptionRepo.Get(ctx, s.testData.subA.ID)
	s.NoError(err)
	s.True(reloadedAfterSecond.CurrentPeriodStart.Equal(t1),
	"CurrentPeriodStart should remain at T1 after the skipped second run")
	}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@internal/service/subscription_threshold_billing_test.go` around lines 272 -
314, The test inserts follow-up events at t1.Add(1*time.Minute) which can be in
the future relative to the immediate second call to
ProcessAutoInvoiceThresholdBilling, so the second run sees an empty window;
change the follow-up insert timestamp to be slightly before the second run (e.g.
t1.Add(-1*time.Minute) or t1.Add(-1*time.Second)) so the events are inside the
new-period window when calling ProcessAutoInvoiceThresholdBilling again; update
the call site that uses s.insertEvents(500, t1.Add(1*time.Minute)) in
TestThresholdBilling_PeriodAdvanceResetsUsageWindow to use a past timestamp
(referencing s.insertEvents and ProcessAutoInvoiceThresholdBilling) so the
second invocation actually evaluates the new period's usage.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Use the subscription returned by CreateSubscriptionInvoice before writing it back.

The rest of this file preserves updatedSub from CreateSubscriptionInvoice before any follow-up SubRepo.Update. Here you ignore that return and then persist the old sub, which can clobber status/payment changes made during invoice creation in the same transaction.

Suggested fix

-	var inv *dto.InvoiceResponse
+	var (
+		inv        *dto.InvoiceResponse
+		updatedSub *subscription.Subscription
+	)
 	if err := s.DB.WithTx(ctx, func(ctx context.Context) error {
 
-		inv, _, err = invoiceService.CreateSubscriptionInvoice(ctx, &dto.CreateSubscriptionInvoiceRequest{
+		inv, updatedSub, err = invoiceService.CreateSubscriptionInvoice(ctx, &dto.CreateSubscriptionInvoiceRequest{
 			SubscriptionID: sub.ID,
 			PeriodStart:    sub.CurrentPeriodStart,
 			PeriodEnd:      effectiveTime,
 			ReferencePoint: types.ReferencePointPeriodEnd,
 			BillingReason:  types.InvoiceBillingReasonAutoInvoiceThreshold,
 		}, paymentParams, types.InvoiceFlowRenewal, false)
 
 		if err != nil {
 			return err
 		}
 
+		if updatedSub != nil {
+			sub = updatedSub
+		}
+
 		// Advance current_period_start only after successful invoice creation.
 		sub.CurrentPeriodStart = effectiveTime
 		if err := s.SubRepo.Update(ctx, sub); err != nil {
 			return err
 		}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@internal/service/subscription.go` around lines 7719 - 7736, The code ignores
the updated subscription returned by invoiceService.CreateSubscriptionInvoice
and instead persists the original sub, which can overwrite status/payment
changes; capture the returned subscription (replace the blank identifier "_"
with a variable like updatedSub), use updatedSub when advancing
CurrentPeriodStart (set updatedSub.CurrentPeriodStart = effectiveTime) and pass
updatedSub to s.SubRepo.Update(ctx, updatedSub) so the transaction persists the
latest subscription state from CreateSubscriptionInvoice.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Don't reuse the normal period-end renewal path for threshold billing.

Line 2949 already documents this CreateSubscriptionInvoice(... ReferencePointPeriodEnd ...) flow as generating both arrear and advance charges at period end. Calling the same path here mid-period means a threshold hit can invoice recurring fixed/advance items before the real renewal boundary, not just the accrued usage since CurrentPeriodStart.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@internal/service/subscription.go` around lines 7721 - 7727, The call to
invoiceService.CreateSubscriptionInvoice is reusing the period-end renewal path
(ReferencePointPeriodEnd and types.InvoiceFlowRenewal) for a mid-period
threshold hit, which causes recurring/advance items to be invoiced incorrectly;
change this to a dedicated threshold-invoice flow by invoking
CreateSubscriptionInvoice with a reference point and flow that represent
threshold billing (e.g., a new ReferencePointThreshold or ReferencePointNow and
a new/explicit types.InvoiceFlowThreshold) or add a boolean/flag to
CreateSubscriptionInvoice to restrict invoicing to accrued usage since
sub.CurrentPeriodStart only; update any callers and enum values
(ReferencePointPeriodEnd, types.InvoiceFlowRenewal) accordingly so threshold
hits do not trigger advance/recurring charges.

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/deploy.yml:
- Around line 86-89: The workflow currently always echoes "${GHCR_IMAGE}:latest"
for IS_RELEASE pushes; change the conditional around the latest tag so it only
emits "${GHCR_IMAGE}:latest" when GITHUB_REF_NAME is a stable semver tag (e.g.,
matches ^v[0-9]+(\.[0-9]+)*$ or does not contain a prerelease separator like '-'
), otherwise skip echoing the latest tag; update the block that prints tags
(referencing GHCR_IMAGE and GITHUB_REF_NAME) to add a shell test (grep -E or [[
]] pattern) that excludes prerelease names such as v1.2.3-rc1 before printing
the latest tag.
- Line 101: Replace the docker build action reference to a v7 release to avoid
Node 16 incompatibility: update the uses entry `uses:
docker/build-push-action@v4` to `uses: docker/build-push-action@v7` (or the
specific tag `@v7.1.0`), then verify the workflow step(s) that call
`docker/build-push-action` still work with the v7 inputs/outputs and adjust any
renamed parameters if needed.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: e9787ca2-a52c-45c2-9674-34a10fa7a247

📥 Commits

Reviewing files that changed from the base of the PR and between ec564b7 and 2fb6156.

📒 Files selected for processing (3)

• .github/workflows/deploy.yml
• internal/api/v1/subscription.go
• internal/types/temporal.go

✅ Files skipped from review due to trivial changes (1)

• internal/api/v1/subscription.go

[coderabbitai]

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Consider filtering pre-releases from the latest tag.

The workflow currently tags every v* push as latest in GHCR. If you publish pre-release versions (e.g., v1.2.3-rc1, v1.2.3-beta), those would incorrectly overwrite the latest tag.

🏷️ Proposed fix to exclude pre-releases from latest tag

            if [ "$IS_RELEASE" = "true" ]; then
              echo "${GHCR_IMAGE}:${GITHUB_SHA}"
              echo "${GHCR_IMAGE}:${GITHUB_REF_NAME}"
-             echo "${GHCR_IMAGE}:latest"
+             # Only tag as latest if not a pre-release (no hyphen in tag name)
+             if [[ ! "$GITHUB_REF_NAME" =~ - ]]; then
+               echo "${GHCR_IMAGE}:latest"
+             fi
            fi

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	if [ "$IS_RELEASE" = "true" ]; then
	echo "${GHCR_IMAGE}:${GITHUB_SHA}"
	echo "${GHCR_IMAGE}:${GITHUB_REF_NAME}"
	echo "${GHCR_IMAGE}:latest"
	if [ "$IS_RELEASE" = "true" ]; then
	echo "${GHCR_IMAGE}:${GITHUB_SHA}"
	echo "${GHCR_IMAGE}:${GITHUB_REF_NAME}"
	# Only tag as latest if not a pre-release (no hyphen in tag name)
	if [[ ! "$GITHUB_REF_NAME" =~ - ]]; then
	echo "${GHCR_IMAGE}:latest"
	fi

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/deploy.yml around lines 86 - 89, The workflow currently
always echoes "${GHCR_IMAGE}:latest" for IS_RELEASE pushes; change the
conditional around the latest tag so it only emits "${GHCR_IMAGE}:latest" when
GITHUB_REF_NAME is a stable semver tag (e.g., matches ^v[0-9]+(\.[0-9]+)*$ or
does not contain a prerelease separator like '-' ), otherwise skip echoing the
latest tag; update the block that prints tags (referencing GHCR_IMAGE and
GITHUB_REF_NAME) to add a shell test (grep -E or [[ ]] pattern) that excludes
prerelease names such as v1.2.3-rc1 before printing the latest tag.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Description: Check the latest version of docker/build-push-action

# Fetch the latest release tag from the GitHub API
gh api repos/docker/build-push-action/releases/latest --jq '.tag_name'

Repository: flexprice/flexprice

Length of output: 70

---

🏁 Script executed:

cd flexprice/flexprice && cat -n .github/workflows/deploy.yml | sed -n '95,115p'

Repository: flexprice/flexprice

Length of output: 133

---

🏁 Script executed:

git ls-files .github/workflows/deploy.yml

Repository: flexprice/flexprice

Length of output: 92

---

🏁 Script executed:

cat -n .github/workflows/deploy.yml | sed -n '95,115p'

Repository: flexprice/flexprice

Length of output: 891

---

🏁 Script executed:

# Check the GitHub Actions warning/error details for this action
# Let's look at the action.yml or any GitHub documentation about version requirements

# First, let's see if there are any other workflow files or documentation that might indicate version constraints
fd -e yml -e yaml .github/ | head -20

Repository: flexprice/flexprice

Length of output: 401

---

🏁 Script executed:

fd -e yml -e yaml . .github/

Repository: flexprice/flexprice

Length of output: 528

---

🏁 Script executed:

rg "docker/build-push-action" .github/

Repository: flexprice/flexprice

Length of output: 216

---

🏁 Script executed:

# Search for any GitHub Actions warnings or documentation about docker/build-push-action@v4
# Let's check the action's releases and migration guide

web_search "docker/build-push-action v4 GitHub Actions compatibility deprecation"

Repository: flexprice/flexprice

Length of output: 114

---

🌐 Web query:

docker/build-push-action v4 deprecated GitHub Actions compatibility

💡 Result:

docker/build-push-action v4 is deprecated and no longer recommended for use in GitHub Actions workflows. The official repository and documentation recommend upgrading to the latest version, which is v7.0.0 as of March 2026 [1][2][3][4][5][6][7]. Older versions like v4 predate major updates, including Node.js runtime upgrades (e.g., from Node 16 in earlier versions to Node 20/24 in later ones) [8][9][10], removal of deprecated environment variables and legacy tools in v7 [1][11], and changes in inputs/outputs in related actions [12][13]. GitHub has deprecated older Node runtimes (e.g., Node 12 for v2/v3, Node 20 nearing deprecation), making v4 incompatible with current GitHub-hosted runners that require newer Actions Runner versions for Node 24 support in v7 [1][12][8]. Workflows using v4 may fail due to runtime deprecations or missing features like improved Buildx support [14][15]. Update your workflow to use docker/build-push-action@v7 alongside companion actions like docker/login-action@v4, docker/setup-qemu-action@v4, and docker/setup-buildx-action@v4 [2][4][5]. Example: name: ci on: push jobs: docker: runs-on: ubuntu-latest steps: - name: Login to Docker Hub uses: docker/login-action@v4 with: username: ${{ vars.DOCKERHUB_USERNAME }} password: ${{ secrets.DOCKERHUB_TOKEN }} - name: Set up QEMU uses: docker/setup-qemu-action@v4 - name: Set up Docker Buildx uses: docker/setup-buildx-action@v4 - name: Build and push uses: docker/build-push-action@v7 with: push: true tags: user/app:latest [2][4]

Citations:

• 1: remove legacy export-build tool support docker/build-push-action#1474
• 2: https://github.com/docker/build-push-action
• 3: https://github.com/docker/build-push-action/releases
• 4: https://docs.docker.com/build/ci/github-actions/multi-platform/
• 5: https://github.com/marketplace/actions/build-and-push-docker-images
• 6: https://github.com/docker/build-push-action?search=1
• 7: https://github.com/docker/build-push-action/
• 8: Migrate from node.js 20 to 24 docker/build-push-action#1444
• 9: Node 16 upgrade docker/build-push-action#724
• 10: chore: upgrade nodejs from 20 to 24 docker/build-push-action#1447
• 11: remove deprecated envs docker/build-push-action#1473
• 12: chore(deps): Bump docker/setup-buildx-action from 3 to 4 docker/build-push-action#1478
• 13: remove deprecated inputs/outputs docker/setup-buildx-action#464
• 14: docker/build-push-action@v4...v5
• 15: https://github.com/docker/build-push-action/tree/v5/

---

Upgrade docker/build-push-action to v7 or later.

docker/build-push-action@v4 uses Node.js 16, which is deprecated on current GitHub Actions runners that require Node 20+. This version incompatibility will cause workflow failures. Upgrade to the latest version (currently v7.1.0).

🧰 Tools

🪛 actionlint (1.7.12)

[error] 101-101: the runner of "docker/build-push-action@v4" action is too old to run on GitHub Actions. update the action's version to fix this issue

(action)

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/deploy.yml at line 101, Replace the docker build action
reference to a v7 release to avoid Node 16 incompatibility: update the uses
entry `uses: docker/build-push-action@v4` to `uses: docker/build-push-action@v7`
(or the specific tag `@v7.1.0`), then verify the workflow step(s) that call
`docker/build-push-action` still work with the v7 inputs/outputs and adjust any
renamed parameters if needed.