Skip to content

feat(dursto): make functions using Resolver return Result#770

Open
NSant215 wants to merge 1 commit intomainfrom
santnr/resolver-fallible
Open

feat(dursto): make functions using Resolver return Result#770
NSant215 wants to merge 1 commit intomainfrom
santnr/resolver-fallible

Conversation

@NSant215
Copy link
Contributor

@NSant215 NSant215 commented Feb 2, 2026

Part of RV-892.
Part of RV-894.

What

Refactor methods using the resolver to return a Result rather than absolute value (though keeping the Error type to Infallible for now, with generic types being introduced in a later PR.

Why

Moves us closer to being able to use the resolver for blinding and lazy loading nodes.

The next step will be to make the Id type and error types generic. This will be done in #795

How

Manually Testing

make all

Tasks for the Author

  • Link all Linear issues related to this MR using magic words (e.g. part of, relates to, closes).
  • Eliminate dead code and other spurious artefacts introduced in your changes.
  • Document new public functions, methods and types.
  • Make sure the documentation for updated functions, methods, and types is correct.
  • Add tests for bugs that have been fixed.
  • Explain changes to regression test captures when applicable.
  • Write commit messages in agreement with our guidelines.
  • Self-review your changes to ensure they are high-quality.
  • Complete all of the above before assigning this MR to reviewers.

@codecov
Copy link

codecov bot commented Feb 2, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.09%. Comparing base (214b4ab) to head (64719e8).

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #770      +/-   ##
==========================================
- Coverage   91.10%   91.09%   -0.01%     
==========================================
  Files         110      110              
  Lines       20913    20913              
  Branches    20913    20913              
==========================================
- Hits        19052    19050       -2     
- Misses       1488     1490       +2     
  Partials      373      373              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@NSant215 NSant215 force-pushed the santnr/resolver-fallible branch 2 times, most recently from f090b73 to d8748ee Compare February 3, 2026 09:46
@NSant215 NSant215 force-pushed the santnr/resolver-fallible branch from d8748ee to 8bd8997 Compare February 3, 2026 14:08
@NSant215 NSant215 force-pushed the santnr/resolver-fallible branch from 8bd8997 to 7b08ced Compare February 3, 2026 14:30
@NSant215 NSant215 force-pushed the santnr/resolver-fallible branch from 7b08ced to 046bb04 Compare February 3, 2026 17:01
@NSant215 NSant215 force-pushed the santnr/resolver-fallible branch 2 times, most recently from edfacfe to ebad67d Compare February 4, 2026 11:05
@NSant215 NSant215 force-pushed the santnr/resolver-fallible branch from ebad67d to b9d2fef Compare February 4, 2026 11:39
@NSant215 NSant215 force-pushed the santnr/resolver-fallible branch from b9d2fef to bd05f39 Compare February 4, 2026 11:43
@NSant215 NSant215 force-pushed the santnr/resolver-fallible branch from bd05f39 to d792b08 Compare February 4, 2026 13:42
@NSant215 NSant215 force-pushed the santnr/resolver-fallible branch from d792b08 to 3b3c0e7 Compare February 4, 2026 13:50
@NSant215 NSant215 force-pushed the santnr/resolver-fallible branch 2 times, most recently from f0b16d3 to 53297e8 Compare February 5, 2026 09:52
Base automatically changed from santnr/resolver to main February 5, 2026 13:07
@NSant215 NSant215 force-pushed the santnr/resolver-fallible branch 3 times, most recently from 10b51d1 to 4b20377 Compare February 6, 2026 17:00
@NSant215 NSant215 changed the title feat(dursto): make Resolver trait fallible feat(dursto): make functions using Resolver return Result Feb 6, 2026
@NSant215 NSant215 force-pushed the santnr/resolver-fallible branch from 54a3a4d to ce9027b Compare February 11, 2026 15:09
@NSant215
Copy link
Contributor Author

I think it would be a good idea to add a commit with a test that uses a fallible implementation of Resolver and asserts that the differentiation between missing nodes and failed resolutions works. It would also help to enforce future changes to Resolver don't depend on the ArcResolver semantics.

@kurtisc I have included such a test in #795 - it requires the type change that @thomasathorne was asking for on the Resolver trait that I am already doing in that MR. Let me know if this is ok

@NSant215 NSant215 force-pushed the santnr/resolver-fallible branch 2 times, most recently from e3ce608 to 1286291 Compare February 11, 2026 17:21
{
let right = node_mut.right_mut();
let (mut min, _, shrank) = Tree::take_min(right, resolver);
let (mut min, _, shrank) = Tree::take_min(right, resolver)?;
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think this method is soundly structured any more. The effect of the mutation that occurs on this line is not undone in case of a failure below. This means, when a failure occurs, the tree is in an inconsistent state. I would imagine this could turn into a foot-gun quite easily. Additionally, avoiding potential exploits to happen by making this correct by construction would probably pay off nicely.

@NSant215 NSant215 force-pushed the santnr/resolver-fallible branch 3 times, most recently from 0db6457 to 6302eda Compare February 12, 2026 15:23
@NSant215 NSant215 force-pushed the santnr/resolver-fallible branch from 6302eda to 2415214 Compare February 12, 2026 17:27
@NSant215 NSant215 changed the base branch from main to ole/push-vtywzosmovko February 12, 2026 17:28
@NSant215 NSant215 force-pushed the santnr/resolver-fallible branch from 2415214 to b139a3b Compare February 12, 2026 17:43
@NSant215
Copy link
Contributor Author

@vapourismo @thomasathorne @kurtisc @emturner @zcabter I have rebased on Ole's error refactor branch that has removed the need for infallible everywhere.

@NSant215 NSant215 requested a review from vapourismo February 12, 2026 17:45
@NSant215 NSant215 force-pushed the santnr/resolver-fallible branch from b139a3b to 4807f6f Compare February 13, 2026 09:33

let data = resolved.to_encode(resolver)?;
let computed = Hash::hash_encodable(data).expect("The hashing should not fail");
let _ = resolved.hash.set(computed); // ignore race: another thread may have set it
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think this is a possible solution - as the hash will be set in either case, but I don't know if another thread setting it will mean that the hash set will not be matching the node then, but not sure of how else to do this

@vapourismo vapourismo force-pushed the ole/push-vtywzosmovko branch from 2edd59c to e14864c Compare February 13, 2026 10:38
@NSant215 NSant215 force-pushed the santnr/resolver-fallible branch from 4807f6f to a178c3b Compare February 13, 2026 11:34
Base automatically changed from ole/push-vtywzosmovko to main February 13, 2026 13:52
@NSant215 NSant215 force-pushed the santnr/resolver-fallible branch from a178c3b to 0e20387 Compare February 13, 2026 13:59
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm curious what you intend to signal with the let _ = ... pattern. I've only come across it when a #[must_use] return value needs to be ignored. Though, I am not convinced that's the case here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

sorry have fixed here

pub(crate) fn to_encode(
&self,
resolver: &impl Resolver<Arc<Node>, Node>,
) -> Result<impl Encode + '_, OperationalError> {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I wish you had introduced the resolver hash method before this, so you wouldn't need to make this encoder fallible.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I didn't think that making the hash method as part of the resolver would be able to make it infallible?

node: &mut Arc<Node>,
resolver: &mut impl Resolver<Arc<Node>, Node>,
) -> Result<(), OperationalError> {
let node_mut = resolver.resolve_mut(node).expect("Node must exist.");
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
let node_mut = resolver.resolve_mut(node).expect("Node must exist.");
let node_mut = resolver.resolve_mut(node)?;

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done here

@NSant215 NSant215 force-pushed the santnr/resolver-fallible branch from 0e20387 to 242ba46 Compare February 15, 2026 14:45
@NSant215 NSant215 force-pushed the santnr/resolver-fallible branch from 242ba46 to 64719e8 Compare February 15, 2026 14:47
@NSant215 NSant215 requested a review from vapourismo February 15, 2026 14:48
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.

6 participants