- Shipped
- September 7, 2026 at 12:48 AM UTC
- Author
- Kamo
- Commit
- 33d6f39
Adding a Telnyx text provider 500'd. The log named it plainly and the screen said nothing useful: constraint **************** Failing row contains (..., 6) Both tables were created by Hibernate's ddl-auto, which writes CHECK (col >= 0 AND col <= N) frozen at the enum's size that day. Appending to an @Enumerated(ORDINAL) enum is safe in Java and fails in the database: bulk_text_provider_instance <= 5 TELNYX is 6 voip_provider_instance <= 4 TELNYX is 6 The VOIP one was already wrong before any of this: JUST_CALL is ordinal 5, so adding a JustCall phone server has been failing since JustCall shipped, with the same shape of 500 and nothing on screen naming the cause. DROPPED, not widened. Raising the bound to <= 6 re-arms the identical trap for whoever appends the next provider, and the enum is already the authority on what a valid value is — the check only adds a second, staler opinion. Applied to the cluster and proved with BEGIN/INSERT/ROLLBACK for ordinals 5 and 6 on both tables; the statement is committed because production DDL here is applied by hand and a fresh environment gets it only from the file. ALSO: a GET on the inbound webhook now answers instead of returning 405. The setup instruction tells an administrator to paste that address into their carrier, and the only way they can check they copied it right is to open it. A POST-only endpoint answered that with "Method Not Allowed" — an error page for a URL that is perfectly correct. It now says so, names the carrier, and reports whether Kamo can actually receive from it. Deliberately dull: this URL is public by construction, so the response carries no org, instance or configuration, and a test asserts it stays that way. That readiness answer had been written twice, in two controllers. It now lives on InboundSmsNormalizer, which is the thing that actually knows.