fix: emulate metadata on standard invoice queries

[turip]

Overview

This patch makes sure that even if we are storing fake data for gathering invoices we are returning the up-to-date data when querying the invoices themselves.

Notes for reviewer

Summary by CodeRabbit

• New Features
  • Gathering-status invoices are now automatically populated with merged customer profile fields, including customer details, supplier info, and workflow/app assignment when retrieved.
• Tests
  • Added test coverage ensuring gathering invoices reflect the expected customer data, supplier information, and workflow app assignment upon retrieval.

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds emulation for Gathering-status invoices: new Service methods fetch and merge customer override/profile data into StandardInvoice fields (Customer, Supplier, Workflow) and integrate this emulation into ListInvoices and GetInvoiceByID. A test verifies merged customer, supplier, and workflow app data.

Changes

Cohort / File(s)	Summary
Gathering Invoice Emulation Helpers openmeter/billing/service/gatheringinvoice.go	Adds two methods: one to emulate merging customer overrides into a slice of billing.StandardInvoice and a wrapper for single invoices. Fetches GetCustomerOverride, caches per CustomerID, merges Customer/Supplier/Workflow fields, and propagates errors.
Invoice Fetching Integration openmeter/billing/service/invoice.go	Calls the emulation on results: ListInvoices pre-processes invoices.Items; GetInvoiceByID conditionally emulates when invoice status is Gathering before further resolution.
Test Coverage test/billing/invoice_test.go	Adds TestGatheringInvoiceEmulation to assert that gathering invoices returned via standard invoice paths reflect merged customer data, supplier info from profile, and workflow app ID.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• refactor: start implementing gathering invoice #3804 — Related gathering-invoice refactor and service/handler changes touching similar gathering invoice processing paths.

Suggested reviewers

• tothandras
• chrisgacsal
• GAlexIHU

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: emulating metadata on standard invoice queries to ensure up-to-date data is returned instead of stale placeholder values.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/emulate-metadata-on-standard-invoice-queries

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🤖 Fix all issues with AI agents

In `@openmeter/billing/service/gatheringinvoice.go`:
- Around line 53-60: The code dereferences mergedProfile.Customer when building
billing.InvoiceCustomer (using mergedProfiles[invoice.CustomerID()] and
assigning invoice.Customer), which can be nil; add a guard that checks if
mergedProfile or mergedProfile.Customer is nil and immediately return a
descriptive error (or propagate a typed error) before constructing
billing.InvoiceCustomer so callers fail fast with a clear message identifying
the invoice/customer ID and that the merged profile has no Customer.

In `@test/billing/invoice_test.go`:
- Around line 4316-4325: Add a test call to BillingService.ListInvoices (e.g.,
s.BillingService.ListInvoices(ctx, billing.ListInvoicesInput{...})) after the
GetInvoiceByID assertions and assert that at least one returned invoice contains
the same emulated Customer, Supplier and Workflow values you validated for
GetInvoiceByID (check fields like invoice.Customer.CustomerID,
invoice.Customer.Name, invoice.Supplier.Name and
invoice.Workflow.Apps.Invoicing.GetID()). Ensure you use the same identifiers
(gatheringInvoiceID/customerEntity/profile/sandboxApp) to match expectations and
fail the test if the list response does not include an invoice with those
emulated values.