Rob Bygrave

> fk_person_who_created (is null on insert) Always nice to reproduce but it does sound like a race condition with replication lag (so we need replication lag to reproduce). It sounds...

> it should be possible to avoid the select from fh_person query, especially if the Person is known because it was created literally a few lines above in the same...

So `personApi.create(email, username,null);` here ... https://github.com/featurehub-io/featurehub/blob/v1.5.7/backend/mr/src/main/java/io/featurehub/mr/resources/oauth2/OAuth2MRAdapter.java#L114 ... that returns `PersonApi.PersonToken` which has the person.id value in it, so we need to capture that returned PersonToken ... and use that for...

I literally just posted and then saw your question :) ... Yes, putting a transaction around the whole lot would mean all the select queries in that transaction are executed...

> However, thats not one request, Yeah I don't quite follow that it's more than 1 request. Is it not that there is 1 request that is both inserting the...

> so if we wrap the appropriate steps (in this case, groups and person) in the same transaction I feel this would solve this specific issue? Yes agreed. That should...

FWIW AWS Aurora Postgres lag is expected to be less than **_200ms_** and I've confirmed that was actually the case. AWS Aurora MySQL replication lag when I measured it in...

Yeah but that isn't this specific issue right? In this case there is only the 1 http request right?

> quite big but not crazy big - 20k rows, 10 columns To me 20k sounds very big. Have you benchmarked that against smaller batch sizes (like batch size 1000,...

Well maybe, in that dirty detection of JSON properties changed in 12.11.1 via: https://github.com/ebean-orm/ebean/pull/2274 We got a bug reported 17 days ago (with a workaround) and fixed 13.6.4 https://github.com/ebean-orm/ebean/issues/2710 And...