Limit customer name and invoice metadata value length

[lago-claude-ai-agent]

Caps customer name at 255 characters and invoice metadata value at 100, mirroring the length limits already enforced on sibling models (entitlement name, customer metadata value). These fields were unbounded, and oversized values break PDF invoice rendering and inflate webhook payloads.

Out of scope: the customer email length limit. email stores comma-separated multiple addresses (it is split on , in the payment-provider sync services), so a single-address cap would reject valid data — an appropriate limit needs a product decision. Email format validation already exists.

[jdenquin]

check before merge that we do not have higher values than limits in prod DB

[lago-claude-ai-agent]

PASS — Adds name max-255 to Customer and value max-100 to InvoiceMetadata, both mirroring existing patterns; CI green, changes contained to 2 models + 2 specs.

Verified:

• Length limits match proven siblings: name (255) mirrors Entitlement::Feature/Privilege; invoice metadata value (100) mirrors CustomerMetadata#value. No half-fix — CustomerMetadata already enforced 100 and ItemMetadata uses a separate JSONB validation.
• Tests are real and cover the boundary (customer name 255 valid / 256 invalid; metadata value 101 invalid) and would have failed on the old code.

Non-blocking nits:

• Neither new test asserts the specific validation error key.
• Metadata value test checks 101 but not the 100 pass boundary.

[groyoh]

@jdenquin we could also add if: :email_changed?. That way we don't need to worry about current data.

[jdenquin]

@jdenquin we could also add if: :email_changed?. That way we don't need to worry about current data.

yes good idea!

[annvelents]

check before merge that we do not have higher values than limits in prod DB

customer_name:
0 on US
46 on EU - some people were trying to hack our orgs 😢 <h1>HACKED YOU</h1><form action=http... - writing to Support about it + some test data

invoice_metadata - no offenders on EU, 2 offenders on US (140 symbols)

Also we need to communicate to customers before merging

[lago-claude-ai-agent]

Thanks for the review! Addressed below.

• @groyoh — add if: :email_changed? so we don't worry about current data: Good call, applied the same idea per field: validates :name, ..., if: :name_changed? on Customer and validates :value, length: ..., if: :value_changed? on InvoiceMetadata (presence kept unconditional). Existing over-limit rows now only fail when their value is actually changed. Added specs covering the unchanged-but-over-limit case.
• @jdenquin — check we don't have values above the limits in prod before merge: Answered below by @annvelents; this remains a pre-merge check on your side (the conditional above means existing rows won't break regardless).
• @jdenquin — "yes good idea!": Done, see the conditional above.
• @annvelents — prod data + communicate to customers before merging: Noted, no code change. The 2 US invoice-metadata rows above 100 chars are covered by if: :value_changed?, so they stay valid until edited. Customer names top out at 46 chars, well under 255. Customer communication is a human step before merge.

[lago-claude-ai-agent]

Held: CI is not green on this PR; not reviewed. Re-run CI, then re-review.

Checks: https://github.com/getlago/lago-api/pull/5880/checks

[lago-claude-ai-agent]

Impediment — no code change to make; remaining items need a human merge decision

Where I stopped

I made no code changes. After reading every unresolved comment against the current branch, the only comment that asked for a code change is already implemented, and the rest are merge-gating decisions that only a human can make.

Why

• "we could also add if: :email_changed? ... don't worry about current data" (approved review) / "yes good idea!" — already implemented on this branch: Customer#name uses if: :name_changed? and InvoiceMetadata#value uses if: :value_changed?, so existing over-limit rows are grandfathered and only revalidated when the field itself is edited. Nothing left to change here.
• "check before merge that we do not have higher values than limits in prod DB" — this was answered in-thread with the prod findings (over-limit customer names on EU incl. injection attempts; 2 over-limit metadata values ~140 chars on US, limit is 100). The changed? guards are exactly what keeps those existing rows from breaking on unrelated updates, so the code side is handled. Deciding what to do with the flagged/malicious rows is a human call.
• "we need to communicate to customers before merging" — a business/process action before enforcing the new limits, not a code change.

Decision a human needs

Whether to proceed to merge, given that:

1. Existing prod rows exceed the new limits and are intentionally grandfathered by the changed? guards (they will only be rejected if the name/value is edited to a still-too-long value).
2. Going forward, API clients setting a customer name > 255 chars or an invoice metadata value > 100 chars will get a validation error — the team wanted to communicate this to customers first.

Both are merge-timing/communication decisions outside the scope of a code edit. No commit was pushed.