What
create_spec fails in production for any summary longer than 255 characters. The failure is instant (~9ms) and surfaces to MCP clients as “the connector’s server isn’t responding”, which looks like a hang but isn’t. The same latent bug affects three other columns.
Root cause (from prod logs)
[error] ** (Postgrex.Error) ERROR 22001 (string_data_right_truncation)
value too long for type character varying(255)
(hive 0.1.0) lib/hive/specs.ex: Hive.Specs.create_spec_transaction/2
Several columns were created as :string (Ecto’s default → varchar(255)) while their changesets validate a longer max. A value between 256 and the validated max passes validation, then crashes the INSERT/UPDATE with SQLSTATE 22001. Because that error isn’t :lock_not_available, it isn’t translated; it propagates, the request 500s, and the MCP connector reports the request as unresponsive.
Fix
Widen each affected column to :text so the changeset limit is the single source of truth (matching body, spec_revisions.summary, domains.description, etc.):
| Column |
Column type before |
Validated max |
specs.summary |
varchar(255) |
280 |
projects.description |
varchar(255) |
500 |
drops.title |
varchar(255) |
500 |
drops.external_id |
varchar(255) |
500 |
varchar(255)→text is a metadata-only change (no table rewrite). Migrations run on deploy via the migrate initContainer (Hive.Release.migrate).
Note
This is the actual fix for the reported “spec creation failing” — separate from #102 (lock-timeout hardening), which fixed a real latent hang but was not what was blocking creation here.
Verification
Will confirm by creating the originally-failing spec (268-char summary) once this deploys.
GA