This might just be an oversight on my part - the # of SURBs to send with each message is configurable in the Destination struct, so you can experiment there.
One more thing from the same log: that single flush line covers five
loaded data is inconsistent. The other four starts died during startup with nothing to flush, and the start after each still called the store inconsistent, so whatever marks it dirty survives until a clean shutdown that never arrives. The window is in the raw log I linked yesterday, and I can send it unfiltered if that reads more easily.
Are you shutting your client down properly (aka using disconnect() and waiting)?
The layer itself stands, and yes to keeping it here rather than scattered. I will post a design note in this thread.
Great, look forward to seeing it.
One question, Max, and it is for our own pinning rather than for you to act on: does the fix have a release, or a target? We are choosing between staying on 1.21.5-rc.3 with the probe compensating and moving the dependency to a
developrev, and the answer decides it.
I published 1.21.5 today - use that. Our release cycle goes in waves, so I will notify you once I have the fixes I have proposed today for the SDK in there and they’re going through QA so you can point at a git rev until they’re released.
One note: don’t use the develop branch if you’re pointing at a git rev instead of using a release from crates.io. developis always going through QA and will change, so won’t be stable; we have our platform and SDK code in the same monorepo.