Log when a create/update entity submission is force applied

[ktuite]

We probably need to log when a submission in the backlog is force-applied. There is currently no (easy) way to know that a submission in the backlog exited the backlog this forceful way (e.g. applying an update when the base/trunk versions don't fit what is in central or applying an update as a create when the create is missing).

We don't track when submissions go into the backlog, and the only related thing we track is when a submission is automatically removed from the backlog because the submission it was waiting on just finished.

This would help with 4. of issue #653 (2024.2 analytics) and I think would be necessary for #702, too (applying create as update).

[matthew-white]

I agree that it would be useful to log this. 👍 Would it be appropriate to log it on the entity def source or the entity def? I could see Frontend wanting to use that information as well one day, so I think we should log it somewhere that's easy for queries to access (maybe not the audit log or not just the audit log).

---

As a side note, I did some quick experimenting with metric 4 of #653. I think you can tell whether an entity version was created after its submission was force-applied from the backlog by comparing the entity version to its base version on the server. However, like you say, the logic is not so simple:

• If trunkVersion == null && branchBaseVersion === 1: is the version number of the base version 1, and is the branchId of the base version null (corresponding to the offline create)? The second condition is to exclude the case where another offline update was force-applied as a create.
• If trunkVersion == null && branchBaseVersion > 1: is the base version the previous version in the same branch?
• If trunkVersion != null && branchBaseVersion === trunkVersion: does the version number of the base version match trunkVersion?
• If trunkVersion != null && branchBaseVersion > trunkVersion: is the base version the previous version in the same branch?

(In all these cases, there should also be a check that there is a branchId and a base version. If there's a branchId but no base version, then that's an offline update force-applied as a create.)

[matthew-white]

For the record, I also think it'd be OK to circle back to this in .3. If there are metrics that rely on this information, we could add those in .3.

[ktuite]

I think this would be good to bump to .3!