2020-08-26 Meeting notes

Owned by Mike Gorrell
Last updated: Aug 26, 2020
2 min read

Date

Attendees

Discussion items

TimeItemWhoNotes

Optimistic Record LockingTC

Review issues (Tech Debt - DEBT-1, UXPROD-1752)  and discuss short term actions:

There was  MODINVSTOR-516 - Getting issue details... STATUS  which should be fixed by  RMB-388 - Getting issue details... STATUS

These issues will be resolved based on serializing activity as opposed to a fundamental design change to address optimistic locking.

Addressing optimistic locking is not likely to be addressed by a single/core team, but likely all backend teams would need to make modifications. In other words, a very big deal. Per UXPROD-1752:

  • optimistic locking – each record state is marked with a "version number" (or a timestamp, hash, etc) which is returned to the client along with the record. The client includes the version number during the update and the server checks that the version hasn't changed before it writes the record back. If the record is dirty (version doesn't match) the update is aborted. In practice for a REST API (typical FOLIO uses case) this means using ETag with a combination of If-Match conditional request and 412 (precondition failed) and 409 (conflict) error codes.

Note that ETags (above) approach may not solve all use cases (batch, pub-sub oriented), etc.

Could "define the requirements"... and put the burden on modules/teams to come up with their own solution... but then we'd have the challenge/cost of potentially independent solutions and separate implementations.

ACTIONS:

1) Ask Jakub Skoczen when UXPROD-1752 might fit on Core:Platform's roadmap

2) Define a recommended standard/approach (e.g. ETags)

3) Get confirmation of this issue's urgency


 Plan to review Tech Debt

Mike Gorrell  

Discuss how we will go about reviewing Tech Debt 

3 steps:

1) Triage the list; what's active, what's the priority, etc. - ACTION - TC members to review list, update/close/etc. in prep for meeting September 9 where we will review entire list together

2) Assign appropriate items to TC members (based on priority, etc.)

3) Define the expectations of TC


Updates on open itemsTC

UI Testing: Zak Burke

  • Dilemma is that Big Test 2.0 is not ready and while it represents an opportunity we have needs right now.
  • No matter what we are looking at making changes to existing tests in order to move to a new/updated framework
  • Might be OK to have multiple frameworks
  • Expect recommendation in the next 2 weeks

Defining Data Types (reference data): Jakub Skoczen

  • Initial meeting is set for tomorrow (8/29)

SAML/SSO issues: Tod Olson

  • Conversation starting

NEXT WEEK
Architectural Blueprint review