fix: Don't compute relative URLs of already relative ones #15
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the last changes I made, I wanted to optimize things a bit as to avoid recomputing URLs again and again by interrogating handlers. But I also introduced a bug: URLs are recorded, but are always made relative. So an already relative URL would be stored, and made relative again, which made it incorrect.
We have three ways to fix this:
split the function in two so that URLs are made relative outside of the recursive function, where URLs are recorded: the change in this PR. Note that the fallback mechanism is able to return an absolute URL (from a loaded inventory). This PR keeps that behavior but maybe that's not something we want (I can't a find a use-case where a handler returns an identifier that is found in an inventory). We must check if an URL is absolute to avoid trying to make it relative.
same as 2 but absolute URLs (from inventories) are never picked up when falling back. We can get rid of the "is absolute?" check: