// It Wasn't Even a Real Dash

Have you ever spent ages debugging something for the root cause to be a missing semi colon on line 67? Most of you probably have, as have I many times. Well here’s a small story about a recent bit of debugging I had to do, and the root cause was something similar, but a little more frustrating.

We have a service that utilises RJSF. React JSON Schema Form. For those of you out of the loop, the library lets you create config schemas on the backend and UI schemas on the frontend. If the backend schema keys match the UI schema keys on the frontend, RJSF renders the forms exactly as you’ve defined them. We use it for rendering loads of forms for anything that, you know.. requires a form obviously. Anyway, that’s beside the point. The key thing to note is that the backend schemas must exactly match the frontend. Exactly. Match.

Ooh, foreshadowing.

// story time

There’s a ticket on the board to add missing form fields to a part of the app where some aren’t displaying, so I pick it up and begin to investigate. I start by loading the form up, confirm the fields aren’t there, and immediately go to the UI schema to see what’s meant to be displaying. “This will be it,” I think. “They just aren’t defined.” Wrong.

{
  "text": "Beginning part U+2013 ending part",
  "component": "correct component",
  "props": {
    "label": "correct",
    "fieldId": "correct",
    "options": "1-5 correct"
  }
}

All of them defined correctly. Ffs.

Second point of call, is the API returning the correct data? I check the logs. Yep, the JSON is correct. Okay, double ffs. What the heck is happening?

Oh, I know. Let me check if they’re defined properly in the database. This is a new product after all and these specific fields might not have been added during the initial implementation. It was built in a major rush, so that’s definitely the problem.

I load up Mongo Compass, connect to the database, find the collection, smile as it loads and then my heart sinks a little. Bro. They’re all there. Sat in the collection perfectly. Every single one of them.

Now I’m thinking “There is absolutely no reason why this isn’t working.”

I get an idea. I’ll do a character for character comparison in VSCode. I open a new window, copy and paste the database schema and the UI schema side by side, and start comparing.

Noice.

The database was defining the text as this:

{
  "text": "Beginning part U+002D ending part"
}

A standard hyphen (-). U+002D. Nothing fancy.

And the UI schema is defining it like this:

{
  "text": "Beginning part U+2013 ending part"
}

An en dash (–). U+2013. Famously beloved by generative AI.

// the end

You can forgive me right now for not immediately noticing the bloody HTML entity codes being ever so slightly different. I have not got hawk eyes, nor does my brain process things as fast as a diff tool - but nonetheless, problem solved. I tested it, pushed up the change, gave the review link to product and they signed it off, done.

Form broken for months, ticket sitting in the backlog for ages and two hours of my time for just – vs -. Fun problem though, I moan, but I did actually enjoy the hunt.

On that note, this is exactly why my post on AI Slop is worth a read. My thought process when working with AI output is what helps prevent small issues like this creeping in unnoticed. An en dash that looks like a hyphen, generated somewhere along the line and never questioned, checked or reviewed properly. That’s AI Slop in its smallest, most annoying form.