Fix internal link format

[gjtorikian]

Actually close #695.

Sorry to trouble you @riccardoporreca but would you be able to validate this works as expected on your end? It seems to be working for me but I'd like to be extra sure.

[riccardoporreca]

@gjtorikian, sure, happy to review and validate... I will have some time over the weekend.

[riccardoporreca]

@gjtorikian, coming back to this later than I originally hoped...

It looks like your new commit 40f8837 includes my very basic attempt to address #695 in riccardoporreca@b9a5cd1 (which includes also log statements and explicit metadata update that we may want to still include)

This however still suffers from what described in #695 (comment) and followed-up in the comments and commits further down in #695, which is the main motivation for introducing context-based keys for internal links (see mainly #695 (comment))

In a sense this PR is addressing only the original PR #696 (before the accidental force-push): I have actually created a "restored" version of the original branch (which I still had locally): main...riccardoporreca:feature/695-fix-internal-cache-metadata-check-restored

Is the intention to go only for this part, perhaps as a first step before reconsidering #695 (comment)?

Let me know what is your intention, I am very keen on helping out also by creating clean branches reflecting what we want to achieve (Git is great for this).

[gjtorikian]

To be honest... I am confused. 😵‍💫 Partly because of my force Git error, but partly also because I don't understand what the error actually is.

Does main...riccardoporreca:feature/695-fix-internal-cache-metadata-check-restored#diff-56f6584338ed220240decc27e7186469985a760ecec8e03071a6545ff370c693 represent the minimal test case for the issue you're noticing?

This PR was mostly meant to address the very first issue spotted in #695. Is there a test case for the issue in #695 (comment) ?

[riccardoporreca]

To be honest... I am confused. face_with_spiral_eyes Partly because of my force Git error, but partly also because I don't understand what the error actually is.

Don't worry @gjtorikian , I probably did not help :) with opening a PR and having a separate "continuation branch" #695 (comment) for proposing the rethinking of internal cache keys to address the additional issue which would not be addressed by the original PR.

In any case, if you see the history of comments and commits (I tried to be very verbose with the messages) following the mention of the additional, more fundamental issue in #695 (comment):

• I introduced in riccardoporreca@b56343f a test case internal links > new failure for cached found url > does recheck failures, regardless of url found for other files revealing the issue, see https://github.com/riccardoporreca/html-proofer/runs/4750865471?check_suite_focus=true#step:6:233
• The new test case was successful after the rethinking of the internal cache key I implemented, see https://github.com/riccardoporreca/html-proofer/runs/4750972114?check_suite_focus=true#step:6:333 (there were however new failures since I did not want to update the other tests to reflect the new cache keys before getting your opinion on the approch, see the last comments in Problems with internal link cache re-checking logic (4.0.0.rc3) #695 (comment).
• The summary of the changes on top of the original PR (which would also apply to this PR) were mentioned in Problems with internal link cache re-checking logic (4.0.0.rc3) #695 (comment), where however the "net" comparison is now visible for the -restored branch at riccardoporreca/html-proofer@feature/695-fix-internal-cache-metadata-check-restored...riccardoporreca:feature/695-investigate-internal-cache-key-metadata

Given this, why don't we proceed as follows?

1. Let's first get this PR merged w/o considering the additional issue and the rethinking of the cache.
   • Here I would only propose to re-include the if not found part of my original commit riccardoporreca@b9a5cd1 (besides the useful debug log, I believe the comments there still apply)
   • A minor "cosmetic" feedback on this PR is about the replacement of arrows with :, where i noticed many double- spaces like : in the README, not sure if that is intentional, e.g.
     

     html-proofer/README.md

     Line 101 in bfa7416

     ], gfm: true

2. I can then create a clean branch a PR for the additional issue and the internal cache key re-thinking, where we can (re)discuss the topic more in detail, unless as of now you believe it is not a direction you would consider.

Of course, feel free to go down any route you believe more sensible.

[gjtorikian]

• A minor "cosmetic" feedback on this PR is about the replacement of arrows with :, where i noticed many double- spaces like : in the README, not sure if that is intentional, e.g.

Thanks! Just a sloppy find-replace.

2. I can then create a clean branch a PR for the additional issue and the internal cache key re-thinking, where we can (re)discuss the topic more in detail, unless as of now you believe it is not a direction you would consider.

This makes sense to me. Thank you for your help.

[riccardoporreca]

@gjtorikian, I have created a clean issue #702 for the open problem, will try later this week to consolidate a new clean PR for the fix as discussed