demo(10-sql-column-truncation): 10 — EF column too short for real-world input

[EricCogen]

10 — EF column too short for real-world input

Expected verdict: ❌ Fails — GauntletCI should fire GCI0050 (SQL column truncation risk).

What changed

A new EF entity configuration under Persistence/Migrations/ declares
the customer-email column as [StringLength(50)]:

public sealed class OrderCustomerSchema
{
    [StringLength(50)]
    public string Email { get; set; } = string.Empty;

    [StringLength(80)]
    public string DisplayName { get; set; } = string.Empty;
}

50 characters is well below the 320-character limit that RFC 5321
permits for an email address, and 80 is below most "full name" inputs
once accents, scripts, and suffixes are included. SQL Server (and
EF Core's default mapping) will silently truncate anything longer
without raising an error.

Why this is risky

• Truncation is silent — the application returns success while the row
  it stored is wrong. Users discover this when their forgot-password
  email never arrives.
• Truncating an email at 50 characters can change who the row points
  to (alice.long-surname@corp.example.com becomes
  alice.long-surname@corp.exa), which is a security incident, not a
  display issue.
• Adding server-side validation that rejects long inputs is a one-line
  change; widening the column is a one-line migration. Either is correct.
  Doing neither is the bug.

What GauntletCI catches

GCI0050 SQL Column Truncation Risk — [StringLength(N)] (or
HasMaxLength(N) / nvarchar(N)) with N < 100 in a file under a
path containing migration / dbcontext / entityconfig / schema.

[github-actions]

GauntletCI found issues in this PR. See inline comments for details.

[github-actions]

GCI0050 — SQL Column Truncation Risk — lines 7, 10

Short string column ([StringLength(50)]) may silently truncate user input

Evidence:

Line 7: [StringLength(50)]
Line 10: [StringLength(80)]

⚠️ Why it matters: A column width of 50 characters will silently drop any input longer than 50 chars at the database layer. If users can provide this value, data loss occurs without an exception — the application continues without any error signal.

💡 Suggested action: Increase the column width (e.g. nvarchar(256) or nvarchar(max)) or add server-side validation that rejects strings longer than 50 characters before they reach the database.

_{Confidence: Medium | Severity: Info | 2 occurrences}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8be9990d26

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Increase persisted email length to fit valid addresses

The Email column is constrained to 50 characters, which is far below real-world valid email lengths; when a user submits an address longer than 50 chars, persistence will either fail or store a truncated value depending on provider/settings. This can break account recovery/login flows for legitimate users with long addresses, so the schema should allow a substantially larger max length (or enforce matching validation before persistence).

Useful? React with 👍 / 👎.