Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate false negatives #4

Open
transitive-bullshit opened this issue Feb 13, 2019 · 17 comments
Open

Investigate false negatives #4

transitive-bullshit opened this issue Feb 13, 2019 · 17 comments
Assignees

Comments

@transitive-bullshit
Copy link
Owner

sindresorhus/awesome-lint#50 (comment)

@transitive-bullshit
Copy link
Owner Author

My guess is these links aren't responding to HEAD and are taking too long to respond to GET requests, but further investigation is needed.

@HorlogeSkynet
Copy link

--> Yes, it happened with https://thinkerview.com/, a WordPress that had been very slow to respond back in the past (and thus failed the CI with awesome-lint).
Unfortunately for you, I don't have any "non-working" example at the moment 🙄

@transitive-bullshit
Copy link
Owner Author

I'm considering increasing the default 10000ms timeout to something larger like 30000ms since I'm really not sure what else can be done in terms of retries or robustness logic.

There will of course always be cases that look like false negatives no matter what (like a server not responding when run from CI but then being alive when the user tries the link manually), but I feel like it shouldn't hurt much to increase the default timeout.

My thinking is that most real invalid URLs will not timeout but rather return an HTTP status code eagerly that got will not retry with and we'll fail fast, whereas sporadically slow to respond servers need more than 10s to respond sometimes.

@davidtheclark @sindresorhus thoughts on this change?

@transitive-bullshit
Copy link
Owner Author

transitive-bullshit commented Feb 14, 2019

Okay; I've update the default timeout to 30000 ms and released v1.1.6.

If anyone else has any ideas on how to improve robustness for mitigating false negatives, please follow up on this thread.

@transitive-bullshit transitive-bullshit removed the bug Something isn't working label Feb 14, 2019
@mischah
Copy link

mischah commented Feb 20, 2019

Hej @transitive-bullshit,

I still have a permanent false negative with this link running awesome-lint on Travis:
https://vimeo.com/181328943

See Travis build log.

According to my package-lock.json check-links 1.1.7 is used.

Locally it’s working fine.

@transitive-bullshit
Copy link
Owner Author

transitive-bullshit commented Feb 21, 2019

Thanks @mischah will investigate what's going on when I have some time.

It's entirely possible that vimeo and other media hosting sites blacklist certain cloud provider IPs like AWS where CI is inevitably being run in order to mitigate piracy, but that's just a hypothesis. It would certainly explain why the vimeo link works locally but isn't accessible via CI.

@sindresorhus
Copy link

Some more: sindresorhus/awesome#1532 (comment)

@sindresorhus
Copy link

Another one: sindresorhus/awesome#1330 (comment)

@stevesong
Copy link

stevesong commented Mar 1, 2019

I have a false negative when running awesome-lint for https://www.facebook.com/ads/audience-insights/people

@sindresorhus
Copy link

@NewAlexandria
Copy link

@HorlogeSkynet
Copy link

HorlogeSkynet commented Apr 29, 2019

Another one : https://creativecommons.org/publicdomain/zero/1.0/

(From CI : https://travis-ci.org/HorlogeSkynet/awesome-thinkerview/builds/526068957 + Deprecation warning ?)

++ 👋

EDIT : ... that is not anymore 🤔

@irazasyed
Copy link

And here's one more: sindresorhus/awesome-lint#88

@jessevdp
Copy link

jessevdp commented Oct 4, 2019

Another false-positive. This one first shows a 500 error, then 1 sec later shows the actual content.

https://blog.ginetta.net/getting-started-with-gatsby-and-cockpit-part-1-of-2-d86871932d44

@innocenzi
Copy link

More false-positives here:

  ×  114:3  Link to https://hellosun.brussels is dead                               remark-lint:no-dead-urls
  ×  236:5  Link to https://codepen.io/adamwathan/pen/RxWrZr is dead                remark-lint:no-dead-urls
  ×  238:5  Link to https://codepen.io/drehimself/full/vpeVMx is dead               remark-lint:no-dead-urls
  ×  244:3  Link to https://codepen.io/joshmanders/pen/PQQBoR is dead               remark-lint:no-dead-urls

@iAdramelk
Copy link

One more example:

  278:37-278:94  warning  Link to https://linuxize.com/post/linux-chown-command/ is dead  no-dead-urls  remark-lint

@undergroundwires
Copy link

undergroundwires commented Apr 23, 2021

ko-fi links do not work anymore, they worked fine until a month ago 🤔

https://ko-fi.com/undergroundwires
https://ko-fi.com/undergroundwires

remarkjs/remark-lint-no-dead-urls#29

undergroundwires added a commit to undergroundwires/Azure-in-bullet-points that referenced this issue Apr 24, 2021
Ko-fi URL has started to be marked as dead URL. The behavior is same with both markdown-link-check (using link-check, tcort/link-check#47) and emark-lint-no-dead-urls (using check-links transitive-bullshit/check-links#4) linters
undergroundwires added a commit to undergroundwires/Azure-in-bullet-points that referenced this issue Apr 24, 2021
Ko-fi URL has started to be marked as dead URL. The behavior is same with both markdown-link-check (using link-check, tcort/link-check#47) and remark-lint-no-dead-urls (using check-links transitive-bullshit/check-links#4) linters
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

No branches or pull requests