With octopus, we can assume frame per message

[ascibisz]

Time Estimate or Size

Small

Problem

Part of cleanup work for transition away from simularium-engine, included in this ticket Link to ticket

Solution

With simularium engine, frame data messages arrived with as much frame data as possible included, up to a certain size. We decided this didn't really optimize performance enough to justify some of the bugs it caused, so octopus only sends one frame at a time. Now, we can handle frame messages from remote simulations nearly the same as we do for local file simulations.

One weird issue that came up is that local file simulation's binary frame data keeps the nAgents param as a binary encoded int, which is what happens in simularium file format. However, octopus / simularium-engine encode nAgents as a binary encoded float. This became obvious when I started combining the local frame data and remote frame data decoding logic. It feels silly to case out how the nAgents value is decoded based on whether it's a local or remote file simulation, so I'm changing how nAgents is encoded in octopus to be an int instead of a float. The PR for that small change is here. I'll have to be intentional about how these PRs get merged, because if one is pushed into staging or production before the other, that environment will break, but since deploying octopus is so easy I'm not overly concerned.

[github-actions[bot]]

jest coverage report 🧪

Total coverage

Status	Category	Percentage	Covered / Total
🔴	Statements	41.07%	2047/4983
🔴	Branches	43.44%	845/1945
🔴	Functions	37.07%	419/1130
🔴	Lines	41.3%	1960/4745

Status of coverage: 🟢 - ok, 🟡 - slightly more than threshold, 🔴 - under the threshold