Refactor ResourceRef expansion

[dantb]

Very small refactor for deduplication. However it's a good example of something done a lot in the codebase - using IO when a weaker data structure would suffice. I find it easier to reason about when this is pushed to call sites since it's clear at a glance that nothing external is involved.

For example here you might think that creating a RootSearch or an OrgSearch does I/O or something, when it's just some parsing which can fail. I think if this approach is adopted more generally, you'll find many more opportunities to refactor / deduplicate and it'll hopefully be more readable. Also testing should become easier, though it probably won't impact integration-style tests as much.

Not sure how much of this is personal preference, so I'm all ears 😄

[shinyhappydan]

I don't really have a strong opinion on this but it feels like Try is a better fit here?

[dantb]

I don't really have a strong opinion on this but it feels like Try is a better fit here?

Hmm I'd agree if we were throwing, but we're only using Throwable as the error channel in a "pure" way here - there's no messing with control flow like with exceptions. Try is ideal for stuff like a FFI to Java code for instance

[olivergrabinski]

I agree that having Either instead of IO in such cases is probably easier to reason about. I don't particularly like having Throwable as the error type; we have more specific types and I think we could use that?

[dantb]

I agree that having Either instead of IO in such cases is probably easier to reason about. I don't particularly like having Throwable as the error type; we have more specific types and I think we could use that?

Forgot to do this here but you're right it could be Rejection. Changed in #4455