Enable the oximeter producer garbage collection RPW#5764
Conversation
|
That's a good question. No, I don't think we have any test that will catch this over-pruning things. This feels like this might be difficult to test, since it's dependent on some specified amount of time passing. But I could imagine a test that advances time through several GC periods, and checks that all the entries in the producer table are still there. It looks like the Happy to help craft that test if you'd like. |
|
Hmm. I'm worried a test like that will be one of:
I guess what I really wish here was a full-scale integration test that's allowed to be slow: deploy the software, wait N minutes, then inspect the state and check for properties like this. For now I've been punting on tests like this and relying on manual checks (madrid/london/dogfood). If you think it's worth adding a test and trying to make it not flaky/slow, I can give it a shot? I'm on the fence. |
|
I agree with that assessment, and also think this test will be flaky or similar. I'm pretty comfortable with the amount of testing we have otherwise, so I think running some manual checks in a development environment seems perfectly fine. |
|
I spot-checked this on I then manually restarted We kept 14 rows for about 10 minutes, but the old mg-ddm stopped getting time_modified bumps as expected (first row in this output): After the 10 minute grace period passed, the GC task pruned that stale Finally, I created 10 instances and waited a couple minutes to confirm they also reregistered themselves periodically (note that |
Closes #5284.
@bnaecker I'm not sure we have any tests that would fail if this starts pruning stuff it shouldn't - do we need to do any kind of manual testing? Or land this and see what happens on dogfood?