Hey @Vlad1 ,

It’s hard to say for sure but there was a bug that we addressed recently that might account for the behavior you’re seeing. I’d need more detailed information that’s probably better not to share on the public forum, so could you raise a support ticket with with the page id or ids that you’re having trouble with and we can take a look for you.

pUpdate] I chatted with support and they already have the necessary information. I’ll take a look at your page and get back to you!

Thanks,

H.Y.

Hi @Vlad1,

I’ve located the problem and fixed it.

Are you creating leads via API by any chance? I want to try to reproduce the problem to see if there’s might be a bug that we haven’t identified.

Thanks!

Hi @hoyan.leung,

Thanks for fixing! Yes, we’re creating leads via API. We’re doing it for multiple customers/keys, but this issue appeared only for this one.

Hi @Vlad1,

I’m afraid I have some bad news to report - while the fix that I applied resolves the issue you’re seeing on the GET to pages/:page_id/leads, the lead (it was just one) that was causing problems is missing some data. I’m working to try to recover as much data as possible but I wanted to make sure you were aware of this.

The underlying problem is that there is a bug in the way the system handles leads with emoji in them. Leads coming in from regular form submissions aren’t a problem (we’ve fixed that) but it looks like for leads created via API it’s still an issue.

We hope to get a fix rolled out shortly - I’ll keep you updated. Feel free to DM me if you have any concerns.

Hi @hoyan.leung

I work with Vlad (but in a different timezone). I’m seeing the “something bad happened” error again. Have you done a rollback?

Can you elaborate on what kind of data was missing? We might need to tweak some reporting.

Hi @john3,

What’s happening is that due to an issue with the way we’ve got the DB configured, we’re unable to properly handle certain types of emoji - when a lead is received that contains data like this, it’s truncated and persisted, which means that when we try to retrieve it, we get errors like the ones you’re seeing. We have a fix in place for regular form submissions (i.e. via pages) but it turns out that leads created via the API take a different code path.

I’m hoping to get a fix deployed soon (hopefully tomorrow). I don’t know what your setup is, but if you have control over the code that’s invoking the API, you could try sanitizing the lead data before it’s sent to our API. If you have your own record of the lead in your system, I can get you a couple pieced of information that you might be able to use to correlate.

As of right now, you have 2 leads that are in this state. What you can expect to see if that, in addition to that API call failing, things like CSV export will likely be broken for you too.

Still getting hundreds of these errors. The lead data looks like plain old ASCII to me. Any update?

@john3,

We’re still working to get a fix out. The lead data that you’re seeing is actually the “good” data - it’s the ones that have emoji characters (that you aren’t going to see) that are causing that /pages/{id}/leads endpoint to error.

Hi @john3, @Vlad1,

The fix to the API has been rolled out so we should be handling emojis on POST calls to /pages/{id}/leads a bit better now. To clarify - we are stripping emoji from the data before we persist it to the database because our DB isn’t (currently) set up in a way that allows us to store emoji in our data.

Unfortunately, there were two leads (that contained emoji) that were not recoverable - the emoji occurred early enough in the payload that there wasn’t much useful data to recover.

Other than that, your CSV exports should be working (and hopefully will continue to work) now.

H