search

microsoft / accessibility-insights-action

Github Action to scan for accessibility issues in github pages
MIT License
80 stars 44 forks source link

Accessibility-insights for azure devops not working and throw exception #1551

Closed SafaaAccount closed 1 year ago

SafaaAccount commented 1 year ago

Describe the bug

The accessibility task was working very well but suddnly it start report this error: node:internal/modules/cjs/loader:1210 return process.dlopen(module, path.toNamespacedPath(filename));

image

Added a new task to install NodeJS version 16 but unfortunately we got a different error: ERROR PuppeteerCrawler: handleRequestFunction failed, reclaiming failed request back to the list or queue {"url":"https://shopin3d-ppe.azurefd.net/en-us/store/shop-in-3d/surfaceprox.html","retryCount":1,"id":"HuyCQqyoK9MYjRm"} Error: Navigation timed out after 60 seconds. at handleRequestTimeout (D:\a_tasks\accessibility-insights_4811a442-2fd3-5aa8-ba1a-14cb7e24c113\3.2.0\node_modules\apify\build\crawlers\crawler_utils.js:19:11) at PuppeteerCrawler._handleNavigationTimeout (D:\a_tasks\accessibility-insights_4811a442-2fd3-5aa8-ba1a-14cb7e24c113\3.2.0\node_modules\apify\build\crawlers\browser_crawler.js:418:54) at PuppeteerCrawler._handleNavigation (D:\a_tasks\accessibility-insights_4811a442-2fd3-5aa8-ba1a-14cb7e24c113\3.2.0\node_modules\apify\build\crawlers\browser_crawler.js:401:18) at runNextTicks (node:internal/process/task_queues:61:5) at processTimers (node:internal/timers:499:9) at async PuppeteerCrawler._handleRequestFunction (D:\a_tasks\accessibility-insights_4811a442-2fd3-5aa8-ba1a-14cb7e24c113\3.2.0\node_modules\apify\build\crawlers\browser_crawler.js:343:13) at async wrap (D:\a_tasks\accessibility-insights_4811a442-2fd3-5aa8-ba1a-14cb7e24c113\3.2.0\node_modules\@apify\timeout\index.js:73:27) image

To Reproduce Steps to reproduce the behavior:

  1. Go to '...'
  2. Click on '...'
  3. Scroll down to '...'
  4. See error

CodePen repro example

Expected behavior

Screenshots

Context (please complete the following information)

Are you willing to submit a PR?

Did you search for similar existing issues?

Additional context

microsoft-github-policy-service[bot] commented 1 year ago

This issue has been marked as ready for team triage; we will triage it in our weekly review and update the issue. Thank you for contributing to Accessibility Insights!

microsoft-github-policy-service[bot] commented 1 year ago

This issue has been marked as ready for team triage; we will triage it in our weekly review and update the issue. Thank you for contributing to Accessibility Insights!

dbjorge commented 1 year ago

Hi @SafaaAccount ,

The first error is likely due to a mismatch between the globally installed version of Node and the version that the build agent is using to run our task. Like you identified, explicitly adding a task to install a matching version of node before running Accessibility Insights is the recommended workaround for the issue; we hope to remove the need for the workaround with #1559.

I'm not sure what the root cause of the second error is. I am able to reproduce it locally using the underlying scanner's CLI package (node C:\repos\accessibility-insights-service\packages\cli\dist\ai-scan-cli.js --crawl --url https://shopin3d-ppe.azurefd.net/en-us/store/shop-in-3d/surfaceprox.html --maxUrls 1 --restart). However, when attempting to load the page locally in a headful Edge/Chrome instance outside the scan CLI, I am able to load the page locally and don't see any obvious persistent network traffic that might be confusing the crawler into thinking the page hasn't finished loading, so I don't think this is an issue of the page legitimately being unreachable or slow to load in your specific CI environment.

This will require further investigation to root cause; the next step for us would probably be to hook up a debugger to the headless browser instance (possibly after reducing the repro to a simpler puppeteer script). We'll try to look more closely into this next week.

microsoft-github-policy-service[bot] commented 1 year ago

This issue requires additional investigation by the Accessibility Insights team. When the issue is ready to be triaged again, we will update the issue with the investigation result and add "status: ready for triage". Thank you for contributing to Accessibility Insights!

microsoft-github-policy-service[bot] commented 1 year ago

This issue requires additional investigation by the Accessibility Insights team. When the issue is ready to be triaged again, we will update the issue with the investigation result and add "status: ready for triage". Thank you for contributing to Accessibility Insights!

dbjorge commented 1 year ago

I'm able to reproduce the second error with a plain Puppeteer test script, both v18.1.0 (used by the current extension) and v19.7.2 (latest as of writing). The issue repros only under old-headless Chromium (ie, not in headful mode, and not with headless: 'new'). The issue repros when asking Puppeteer to waitUntil: 'networkidle2' (what the scanner uses) or networkidle0, but not load or domcontentloaded. The issue does not repro in latest Playwright (v1.31.1) waiting for networkidle.

I'm still not sure why the problematic Puppeteer configuration times out - I took a trace of the interaction and there are several periods of network inactivity present in the trace which I'd have expected to trigger either of the two networkidle lifecycle events.

Unfortunately, we likely won't prioritize debugging this particularly, since:

As a workaround, we'd encourage you to automate testing of this site by using a Playwright-based end to end test (docs, sample), rather than using the Azure DevOps task for this specific site.