It's a bit confusing to use 'id' and 'UUID' interchangeably.

It seems a bit weird that teamId above is another-team-uuid and below it is team-a-uuid. Are these deliberately different/why is this working if they're different? 🤔

It seems a bit weird that teamId above is another-team-uuid and below it is team-a-uuid. Are these deliberately different/why is this working if they're different? 🤔

😅 it's a way to workaround for the shared global cache. otherwise, it's hard to assert the behavior.

I plan on refactoring the graphql client out of its standalone pkg. at least, during test, we can start from a clean state everytime

Not entirely sure what the benefit is of an extra level of optionality here with 'modifier' (which is also a bit awkward name-wise); for example, GitHub Actions YAML mixes optional and non-optional keys together at the same 'level' in the tree. But it's not a big deal.

Is the point that problems with fields outside of modifier: will result in "hard errors" whereas problems with fields inside of modifier: will result in "soft errors"? If so, it would be useful to document that property on modifier: rather than on projectName:.

yeah, that's the intention. modifer is a collection of best-effort modification we will make when moving the issue

Not entirely sure what the benefit is of an extra level of optionality here with 'modifier'

😂 I think I am too used to the craziness of k8s API. That said, I agree, we shouldn't have more too much nesting