[FOLIO-1735] Unable to login due to unrecognised staffSlips property when deserialising a service point Created: 25/Jan/19 Updated: 03/Jun/20 Resolved: 04/Feb/19 |
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | Continuous Integration |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Bug | Priority: | P1 |
| Reporter: | Marc Johnson | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | platform-backlog | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||
| Sprint: | |||||||||||||||||||||
| Description |
|
Summary It is not possible to login using mod-users-bl in any environment due to a new property on a service-point not being recognised during deserialisation. In effect, this means any new property additions to records where this deserialisation is used become breaking. Testing Environment This morning, the folio-testing-backend build failed with the following error. Symptoms TASK [folio-ansible/roles/tenant-admin-permissions : Login as diku_admin] ******
fatal: [10.36.1.138]: FAILED! => {"accept": "application/json, text/plain", "accept_encoding": "identity", "changed": false, "connection": "close", "content": "Unrecognized field \"staffSlips\" (class org.folio.rest.jaxrs.model.ServicePoint), not marked as ignorable (9 known properties: \"pickupLocation\", \"locationIds\", \"shelvingLagTime\", \"id\", \"description\", \"code\", \"metadata\", \"name\", \"discoveryDisplayName\"])\n at [Source: (String)\"{\"id\":\"c4c90014-c8c9-4ade-8f24-b5e313319f4b\",\"name\":\"Circ Desk 2\",\"code\":\"cd2\",\"discoveryDisplayName\":\"Circulation Desk -- Back Entrance\",\"staffSlips\":[]}\"; line: 1, column: 153] (through reference chain: org.folio.rest.jaxrs.model.ServicePoint[\"staffSlips\"])", "content_type": "text/plain", "host": "10.36.1.138:9130", "msg": "Status code was 500 and not [201]: HTTP Error 500: Internal Server Error", "redirected": false, "status": 500, "transfer_encoding": "chunked", "url": "http://10.36.1.138:9130/bl-users/login", "user_agent": "ansible-httpget", "x_okapi_match_path_pattern": "/bl-users/login", "x_okapi_permissions": "[]", "x_okapi_request_id": "755759/bl-users", "x_okapi_request_ip": "10.36.1.138", "x_okapi_request_method": "POST", "x_okapi_request_timestamp": "1548381964988", "x_okapi_tenant": "diku", "x_okapi_token": "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJVTkRFRklORURfVVNFUl9fMTAuMzYuMS4xMzg6MzcxMjZfXzIwMTktMDEtMjVUMDI6MDY6MDQuOTg5KzAwMDAiLCJtb2R1bGUiOiJtb2QtdXNlcnMtYmwtNC4zLjMtU05BUFNIT1QuNTUiLCJleHRyYV9wZXJtaXNzaW9ucyI6WyJ1c2Vycy5pdGVtLmdldCIsInVzZXJzLmNvbGxlY3Rpb24uZ2V0IiwicGVybXMudXNlcnMuaXRlbS5nZXQiLCJwZXJtcy51c2Vycy5nZXQiLCJ1c2VyZ3JvdXBzLml0ZW0uZ2V0IiwiaW52ZW50b3J5LXN0b3JhZ2Uuc2VydmljZS1wb2ludHMtdXNlcnMuY29sbGVjdGlvbi5nZXQiLCJpbnZlbnRvcnktc3RvcmFnZS5zZXJ2aWNlLXBvaW50cy11c2Vycy5pdGVtLmdldCIsImludmVudG9yeS1zdG9yYWdlLnNlcnZpY2UtcG9pbnRzLmNvbGxlY3Rpb24uZ2V0IiwiaW52ZW50b3J5LXN0b3JhZ2Uuc2VydmljZS1wb2ludHMuaXRlbS5nZXQiXSwicmVxdWVzdF9pZCI6Ijc1NTc1OVwvYmwtdXNlcnMiLCJ0ZW5hbnQiOiJkaWt1In0.YwcKqYH4Hn6tW7d0JqlrJ6scVQXHKfsZNqTJT-GM_zg", "x_okapi_trace": "POST mod-authtoken-2.0.5-SNAPSHOT.41 http://10.36.1.138:9131/bl-users/login : 202 1337us, POST mod-audit-filter-0.0.5-SNAPSHOT.23 http://10.36.1.138:9161/bl-users/login : 200 639us, POST mod-users-bl-4.3.3-SNAPSHOT.55 http://10.36.1.138:9139/bl-users/login : 500 149351us, POST mod-audit-filter-0.0.5-SNAPSHOT.23 http://10.36.1.138:9161/bl-users/login : 200 1214us", "x_okapi_url": "http://10.36.1.138:9130"}
to retry, use: --limit @/home/jenkins/workspace/Automation/folio-testing-backend01/CI/ansible/folio-testing-backend.retry
Situation A new staffSlips property was added to the service point record definition by Matt Reno and merged yesterday. Investigation so far
The new module version wasn't deployed and the sample data had been updated to include a property it did not recognise. My understanding is that mod-inventory-storage now loads the reference records during the Tenant API call but uses the same source directory in the repository as before. The sample service desk records do not seem to have been updated with this property. And the version deployed is the latest, which supports this property - mod-inventory-storage-14.1.0-SNAPSHOT.224 from the build log and jenkins history. Hypothesis 2: Client that does not accept new properties The okapi trace output does not report mod-inventory-storage at all. "x_okapi_trace": "POST mod-authtoken-2.0.5-SNAPSHOT.41 http://10.36.1.138:9131/bl-users/login : 202 1337us, POST mod-audit-filter-0.0.5-SNAPSHOT.23 http://10.36.1.138:9161/bl-users/login : 200 639us, POST mod-users-bl-4.3.3-SNAPSHOT.55 http://10.36.1.138:9139/bl-users/login : 500 149351us, POST mod-audit-filter-0.0.5-SNAPSHOT.23 http://10.36.1.138:9161/bl-users/login : 200 1214us", "x_okapi_url": "http://10.36.1.138:9130"} Could this be that the RAML Module Builder defaults array properties to an empty array (Julian Ladisch Adam Dickmeiss can you confirm that) so the sample reference records will have the staffSlips property when fetched? And that we have a module that fetches service-points, maybe mod-users-bl (because it features in the okapi trace), using a client which does not accept unrecognised properties (in effect making the addition of a new property fatal)? "Unrecognized field \"staffSlips\" (class org.folio.rest.jaxrs.model.ServicePoint), not marked as ignorable It would appear the mod-users-bl does try to convert each service point to a instance of a class: https://github.com/folio-org/mod-users-bl/blob/90fd0a9f4b12b31edf1af6b6092ffab4598b64ec/src/main/java/org/folio/rest/impl/BLUsersAPI.java#L939 This likely depends upon how the deserlisation in RAML Module Builder behaves - https://github.com/folio-org/raml-module-builder/blob/087e899fd2dc12758da09462e52844431c2b30ab/domain-models-runtime/src/main/java/org/folio/rest/tools/client/Response.java#L366 - Adam Dickmeiss Julian Ladisch does this seem plausible? Snapshot Environment This issue did not fail the folio-snapshot environment build, however it does prevent logging in effectively making this environment unavailable as well. |
| Comments |
| Comment by Julian Ladisch [ 25/Jan/19 ] |
|
Yes, if an array field is missing the deserialisation returns an empty array.
{
"id": "c4c90014-c8c9-4ade-8f24-b5e313319f4b",
"name": "Circ Desk 2",
"code": "cd2",
"discoveryDisplayName": "Circulation Desk -- Back Entrance"
}
to the /service-points endpoint it returns
{
"id" : "c4c90014-c8c9-4ade-8f24-b5e313319f4b",
"name" : "Circ Desk 2",
"code" : "cd2",
"discoveryDisplayName" : "Circulation Desk -- Back Entrance",
"staffSlips" : [ ]
}
The staffSlips property has been added to mod-inventory-storage 18 hours ago (2019-01-24 04:44 CET): |
| Comment by Julian Ladisch [ 25/Jan/19 ] |
|
Snapshot uses only released versions of backend modules, there isn't a mod-inventory-storage release with staffSlips yet, it's in master only. |
| Comment by Marc Johnson [ 25/Jan/19 ] |
|
A temporary hack resolution for this could be a new build of mod-users-bl with an updated service point schema that includes the staffSlips property. Kurt Nordstrom What do you think? (I believe this is temporary because I think a better way to resolve this would be to make the deserialisation in this context ignore properties it does not understand) |
| Comment by Marc Johnson [ 25/Jan/19 ] |
|
Julian Ladisch Apologies, I missed your comment above. Does that mean you believe the (temporary) solution I proposed above may resolve this? |
| Comment by Julian Ladisch [ 25/Jan/19 ] |
|
I think the solution resolves this and is a permanent solution. |