500 Internal Server Error when posting applications

Hi,

We’re getting 500 Internal Server error when posting applications to the API. How do we get more informative error messages to solve our issue?

I do not believe it is an issue with our JSON as if I remove one of the mandatory field, I do get a correct validation message.

The JSON we’re trying to send is quite large, so I cannot attach it in here.

Regards,

Paul

When you get the 500 response, there should be a request ID header returned. If you give me that I can look it up in our logs and see if I can diagnose the issue.

Hi Anthony,

Does the below help?

Date →Tue, 04 Sep 2018 09:58:31 GMT X-Request-Id →8b4d655d-9e53-4585-8224-1091b5f3f255

I’ve also done another request now to give more recent logs:

Date →Wed, 05 Sep 2018 21:45:04 GMT X-Request-Id →212911a4-c66b-40b8-8dc6-90fe09afe725

Regards,

Paul

So, I found the logs and can definitely see something going wrong, however I can’t seem to reproduce it on my end. Could you email me (anthony@catsone.com) an example json body that is causing the 500 to occur? Once I can reproduce the issue I should be able to track down what data the submit code doesn’t seem to like.

I’ve sent the email.

It looks like the issue is with field id 21023, you are setting the value to an object but the field itself is a text field. I will be adding in some validation checking for that scenario so it doesn’t return a 500 anymore and it actually tells you what is going wrong. In the mean time, if you fix that field does it start working as expected?

I am now getting validation errors (see below), even though I am providing values for the fields that it says are missing.

{
    "message": "Validation failed.",
    "errors": [
        "Citizenship is a required field.",
        "Employment Type is a required field."
    ]
}

For reference, I set field 21023 (Citizenship) to a string , it still returned a 500 Internal server error. Then I also set field 21027 (Employment Type) to a string as it is marked as a text field as well with radio selection options, this made the 500 error go away but I am getting the above validation error.

That is very strange. If those application fields are set to save to a custom field that is of the type radio, then the application field itself should be marked as radio, not text. I’ve tried creating a couple applications and custom fields on my test site that mirror yours and they are always created correctly (the type of the application field is always radio which in turn allows a json object to be set as the value).

Do you have any knowledge of how those custom fields were created, or how the applications fields were linked to them? Without being able to get my data into the same state as yours, it’s hard to diagnose the original issue that would have caused those fields to get into that mismatched state. All the normal methods of creating application fields on my site result in what I’d expect.

Could you perhaps try recreating those application fields in the UI and re-linking them to the custom fields, and then seeing if the new application fields of are of the correct type? Once those application fields become the correct type, then your original json should start working (you’ll just need to change the old application fields ids to the newly created ones). If you are unable to get those fields create as radio fields, then I’ll have to dig into why your site in particular is having that issue and not mine.

I’m not across how those fields were created. I only have access to the API.

I’ll raise these questions / suggestions with our customer and see how I go and get back to you later today.

Hi Anthony,

The issue is on our customer’s production site, we do not have that issue on our testing site either.

Given it is a production site, we do not wish to make changes to these questions given that they already have jobs published with these questions and using the direct application page (not via the API). I will forward an email to your direct email address with some screenshots of the configuration.

We need your team to resolve the issue in the production environment.

I have changed the type of those two fields to radio for you, however I can’t be sure of any other side-effects whatever caused it to be created as a text field in the first place might have had, so you’ll have to let me know if everything appears to be working fine now or if anything else is acting weird.

Thank you for your help Anthony. I have now gone past those fields, I’m also having issues with the next set of fields. I’ve gone through all the fields in the different application templates they have and come up with the following fields that have those inconsistencies.

Are you able to resolve it for those fields as well?

Application Id 2863

Fields

21264

21265

Application Id 2972

Fields

22115

22116

22118

22119

22120

22121

22122

22123

22124

22125

Thank you for your help.

All those fields should be fixed. I still don’t know what caused those discrepancies in the first place, so let me know if you see anything else strange with them.

Some good news. I have managed to successfully send an application via the API.

Thanks for your help Anthony.