You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I met you at the Bullhorn Engage Conference. I am one half of Matador Jobs (for WordPress) and a Marketplace Partner. I asked a question during the Developer Q&A where to submit bug reports for the API, and I was told here (even though this GH isn't for the REST API per se). So here goes.
I have a client who has received two applications this week that have caused Matador to fail. Here is what is happening (normally):
Matador, submits the candidates' resume file to Bullhorn via a resume/parseToCandidate call.
Matador manipulates the object
Matador, tries to create a candidate with the returned object.
Note: Because this a real candidate, I omitted sensitive data, but a firstName, lastName, and more was present, as expected.
So, I am confident I've narrowed this to resume/parseToCandidate returning an invalid candidate object. This is a pretty rough bug, and I hope you agree. I understand why namePrefix has a character limit, but I don't understand why the parser is giving me an invalid object back.
To address this issue while you work on this, Matador is seeing its error handling improved in this area, but ultimately, this is not something we can fix. We do not want to, nor do we think we should need to, write a validator for data returned to us via the API. The candidate object is massive and a validator will cost resources and processing time we don't want, and we feel strongly that what we get back from Bullhorn should be reliable.
I am 100% committed to helping the team address this issue and in fact have the resume in question (client data and all) available for you guys to use in recreating this bug. Please, email me at jeremy - at - matadorjobs - dot - com and I'll send you the candidates resume so you can recreate this error. I am not on GH every day (like I am on bitbucket) so the fastest replies for me might be via email.
The text was updated successfully, but these errors were encountered:
To be clear, when I say "resume/parseToCandidate returning an invalid candidate object" I'm referring to a candidate object where namePrefix is allowed to have more than 5 characters, even though entity/Candidate does not allow more than 5 characters.
Hi Bullhorn Team,
I met you at the Bullhorn Engage Conference. I am one half of Matador Jobs (for WordPress) and a Marketplace Partner. I asked a question during the Developer Q&A where to submit bug reports for the API, and I was told here (even though this GH isn't for the REST API per se). So here goes.
I have a client who has received two applications this week that have caused Matador to fail. Here is what is happening (normally):
For this candidate, the call fails. The error is:
stdClass Object ( [errorMessage] => error persisting an entity of type: Candidate [errorMessageKey] => errors.cannotPersistEntity [errorCode] => 500 [errors] => Array ( [0] => stdClass Object ( [propertyName] => nameSuffix [maxLength] => 5 [severity] => ERROR [type] => PROPERTY_VALUE_TOO_LONG ) ) [entityName] => Candidate )
To narrow down this bug, I turned off any manipulation of the object. So my test runs in exactly this order:
The call still failed with the same error. So I inspected the returned object from the resume/parseToCandidate call. I found this:
object(stdClass)#1158 (5) { ["confidenceScore"]=> string(5) "58.33" ["candidate"]=> object(stdClass)#1159 (10) { ["omitted_fields_for_security]=> (...), ["nameSuffix"]=> string(29) "Oracle Certified Professional" } }
Note: Because this a real candidate, I omitted sensitive data, but a firstName, lastName, and more was present, as expected.
So, I am confident I've narrowed this to resume/parseToCandidate returning an invalid candidate object. This is a pretty rough bug, and I hope you agree. I understand why namePrefix has a character limit, but I don't understand why the parser is giving me an invalid object back.
To address this issue while you work on this, Matador is seeing its error handling improved in this area, but ultimately, this is not something we can fix. We do not want to, nor do we think we should need to, write a validator for data returned to us via the API. The candidate object is massive and a validator will cost resources and processing time we don't want, and we feel strongly that what we get back from Bullhorn should be reliable.
I am 100% committed to helping the team address this issue and in fact have the resume in question (client data and all) available for you guys to use in recreating this bug. Please, email me at jeremy - at - matadorjobs - dot - com and I'll send you the candidates resume so you can recreate this error. I am not on GH every day (like I am on bitbucket) so the fastest replies for me might be via email.
The text was updated successfully, but these errors were encountered: