Unassigning for now; this case is actually pretty hard to trigger with recent changes.

to reproduce this bug:

Ah! I didn't see your comment. No, I just meant deleting them from the internal representation in the Implementation object within the orchestrator. I wanna discuss this tomorrow in the eng meeting.

The patch doesn't cause an error to be raised. Instead, in this case, it sets useReentrance to false (to avoid the error altogether) AND logs a warning. Moving to QA

This happens because the evaluator and wiki stubs aren't being properly populated. Presumably, when mocha filters tests, it runs the tests before certain other bits of config have had a chance to run.

this is really hard to do ...

setZMapValue also needs to call findIdentity to learn key and value types.

The docstring for isZMap says, "Does not validate the ZObject." Is it necessary that the object not be run through a validator for any reason? I'd like to alter this function to call findIdentity, which will fix the bug but will add a validation step for type-checking. @DMartin-WMF , any thoughts?

Hmm, I'm assuming we'll handle the memory limit bit in Kube. Let's keep this open for that (unless there's already another, more specific task to cover that).

There are some things we still need to think through about the Helm charts and Kube configuration.

We can't meaningfully fix this right now. I suggest doing what you did with Kleenean and just make the identity field a Z6 instead of a Z9.