Remove host remark length limit

[Katze-942]

I checked almost all clients and did not find any hard 40-character limits for host names. I think the current limit is unnecessary and sometimes only gets in the way.

For example, I recently wanted to create an experimental configuration, but the 40-character limit made it difficult to describe what the profile was for, so I had to omit or shorten a lot of details.

This PR should remove the limit by updating the backend contract and persistence layer. Frontend builds that consume the updated contract will inherit the relaxed validation.

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[what-the-diff]

PR Summary

• Unlimited Comment Character Length

  • Removed the restriction that previously limited comment length to 40 characters in the system. This allows the user to add extensive remarks if required.

• Database Update to Accommodate Longer Remarks

  • The database was modified to support this change. In specific, the column handling remarks in our host data was altered to accommodate longer text entries.

• Updated System Data Model

  • The data model of the system, defined in Prisma, was updated to reflect the removal of the length limit on the remark field. Now, it allows unlimited character entry in line with the previous changes.

[greptile-apps]

Greptile Summary

This PR removes the 40-character Zod validation limit on the host remark field and migrates the DB column from VARCHAR(50) to TEXT, eliminating both the application-level and storage-level caps entirely.

• Contract layer (create.command.ts, update.command.ts): .max(40) is dropped from both schemas; no replacement upper bound is added, leaving remark length fully unbounded at the API level.
• Persistence layer (schema.prisma, migration): remark is correctly altered from VARCHAR(50) to TEXT; the migration is non-destructive and safe for existing data.

Confidence Score: 4/5

Safe to merge; the migration is non-destructive and both contract files change only a validation removal.

The DB migration is correct and backward-compatible. The main open question is whether dropping all upper-bound validation on remark — with no replacement limit — is intentional; the update command also has no minimum-length guard, so an empty string remark can be persisted via the update path.

Both Zod command files (create.command.ts and update.command.ts) warrant a second look for the missing upper bound and the asymmetric min-length handling.

Important Files Changed

Filename	Overview
libs/contract/commands/hosts/create.command.ts	Removes .max(40) from remark Zod validation; .min(1) is retained, but no new upper bound is set.
libs/contract/commands/hosts/update.command.ts	Removes .max(40) from remark Zod validation; no min-length guard present, allowing empty string remarks on update.
prisma/migrations/20260520223000_remove_host_remark_limit/migration.sql	Correctly alters hosts.remark from VARCHAR(50) to TEXT; migration is safe for existing data.
prisma/schema.prisma	Drops @db.VarChar(50) from Hosts.remark, aligning the Prisma model with the new TEXT migration.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[API Request: remark field] --> B{Zod validation\ncreate.command.ts}
    B -- "min(1) ✅\nmax: none ⚠️" --> C[Controller]
    A2[API Request: remark field] --> B2{Zod validation\nupdate.command.ts}
    B2 -- "optional, no min,\nno max ⚠️" --> C
    C --> D[Prisma ORM]
    D --> E[(PostgreSQL\nhosts.remark TEXT)]

Loading

Comments Outside Diff (2)

1. libs/contract/commands/hosts/create.command.ts, line 28-34 (link)

   No upper bound on remark length

   Removing the max(40) constraint without introducing a new reasonable ceiling means the API now accepts arbitrarily long strings for remark. A very large payload passed to this field could stress the persistence layer or waste DB storage, and there is no defence in either the Zod schema or the DB column (now TEXT). A generous but finite limit — e.g. .max(255) or .max(512) — would still satisfy the stated goal of supporting descriptive remarks while preserving basic input hygiene.

2. libs/contract/commands/hosts/update.command.ts, line 32-36 (link)

   Update allows empty remark string

   The create command enforces .min(1) (remark must be at least 1 character), but the update command has no equivalent minimum-length guard. A caller can send remark: "" and it will pass Zod validation, potentially persisting an empty remark in the DB. This inconsistency predates the PR but is now more visible given the constraint review. Adding .min(1) here would align both commands.

_{Reviews (1): Last reviewed commit: "fix: remove host remark length limit" | Re-trigger Greptile}