Tags: asSqr/genie
Tags
Remove read only from most query peristence API's Given the unknown nature of how the system is deployed `readOnly = true` can behave in different ways. For example with amazon aurora and the mariadb driver if you set `readOnly = true` it will send all the requests to a read replica endpoint which is subject to lag and inconsistency. There is no serializable isolation level. While the potential benefits here are nice it is not worth the risk of side effects both within the system codebase itself as modules are replaced with unknown implementations or to the REST API clients who expect consistent responses (e.g. read after write from HTTP 200 responses). Removing `readOnly = true` from all but the non-critical search API's may slow down some performance due to JPA flush and context evaluation but the consistency gaurantees are likely worth the tradeoff for most of these queries which are point queries anyway to index backed columns.
Fix exposing inconsistency in job status outside of persistence API Within job launch logic there was a helper method which would query the job status and based on the returned value proceed with some logic to either update it or fall back to other logic. This works ok if all requests to the persistence service implementation go to a single cosistent backend. If, however, read only queries go to a read replica which may have lag or some other implementation entirely this breaks down without the service actually knowing why or how. Moving the logic for this behind the persistence API and letting the launch service only act the returned job status from the source of truth api should fix this problem.
Standardize JSON serialization of V3 API model insant fields Previously the JSON serialization relied on the default Jackson behavior which was to defer to `toString()` however that followed the ISO standard and would serialize to whatever fractionional number of digits were available. On Java 8 JDKs this was ok as it would always do milliseconds. On a Java 11 JDK it would expand to 6 digits of precision which still adhers to the spec. The problem was that within Netflix there is a widely used client with a long upgrade path that hardcoded some 3 digit precision expectation in its parsing rather than using a standard ISO8601 parsing library for the time strings returned by the API. This change creates a custom serializer which truncates all available Instants to millisecond precition before preceeding with the standard serialization logic of calling `toStriong()`. This should ensure backwards compatibility as we run the server on Java 11 JDKs.
Make attachments for job requests optional For backwards compatibility some internal clients were sending requests to the multipart endpoint but not sending an attachment field. This worked on the 2.3.x line but on 2.5.x it is enforced more strictly and is throwing 400. The proper thing to do would be to make the clients do the right thing but it would be such a long tail that releasing this fix is more effective short term while that logic is slowly phased out.
PreviousNext