Skip to content

Conversation

@lann
Copy link
Collaborator

@lann lann commented Oct 1, 2025

I'd like to avoid the implicit calls to get required by the current implementation. I'm not attached to specifics here otherwise.

@lann lann requested a review from itowlson October 1, 2025 18:15
///
/// Dynamic resolvers will typically return true unconditionally, which is
/// the default implementation.
fn may_resolve(&self, key: &Key) -> bool {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm trying to capture some subtlety in the name here: a Provider should only return false if it "knows" resolution would later fail; it is always safe to return true.

if !resolved {
unvalidated_keys.push(key);
let mut unresolvable_keys = vec![];
for key in self.internal.required_variables() {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing I liked about the previous approach was that it allowed for a quick upfront check: do we have any dynamic providers in the mix, if so don't bother with checking individual variables. But in practice I guess the performance overhead of always checking every variable is insignificant.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't be surprised if we saved more cycles in a single CI run by these tests no longer needing to set up a tokio runtime than we ever lose to this deoptimization. 🙂

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

chuckle

@lann lann force-pushed the provider-may-resolve branch 3 times, most recently from 95e6709 to 363a537 Compare October 1, 2025 20:59
Signed-off-by: Lann Martin <lann.martin@fermyon.com>
@lann lann force-pushed the provider-may-resolve branch from 363a537 to 294ad3a Compare October 3, 2025 12:46
@lann lann merged commit 22322aa into main Oct 3, 2025
31 of 33 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants