[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:
Blocks
is blocked by MODUSERBL-64 Add staffSlips array to servicepoint.... Closed
Relates
relates to MODINVSTOR-235 Backend Work for UISP-6: Add print by... Closed
relates to FOLIO-1736 SPIKE: When used by clients, JSON sch... Closed
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

Hypothesis 1: Mismatch between sample reference records and module

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.
When posting

{
  "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):
https://github.com/folio-org/mod-inventory-storage/pull/226/files
mod-users-bl's servicepoint.json does not contain staffSlips yet:
https://github.com/folio-org/mod-users-bl/blob/master/ramls/servicepoint.json

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.
https://dev.folio.org/guides/automation/#folio-snapshot

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.

Generated at Thu Feb 08 23:15:32 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.