Skip to content
This repository has been archived by the owner on Jan 30, 2025. It is now read-only.

Cannot find context with specified id #49

Closed
inancgumus opened this issue Nov 1, 2021 · 11 comments · Fixed by #169
Closed

Cannot find context with specified id #49

inancgumus opened this issue Nov 1, 2021 · 11 comments · Fixed by #169
Assignees
Labels
bug Something isn't working next Might be eligible for the next planning (not guaranteed!)

Comments

@inancgumus
Copy link
Member

inancgumus commented Nov 1, 2021

Reported by Tom on Oct, 30th:

  • I was getting nil pointer exceptions here and somewhere here as a result of frame being nil. Moving the if blocks inside the preceding if frame != nil block got me past these. Not sure what the implications are beyond that though, but I guess having a nil frame is expected if there's already code checking for that condition?! 😅
  • Currently seeing a ERRO[0026] unable to evaluate expression: Cannot find context with specified id (-32000). Not sure why - I think this was working before I pulled the latest xk6-browser.
  • Also seeing a panic: send on closed channel but I think that might be happening as a result of earlier errors (like the above), i.e. during shutdown.
Example stack trace
panic: send on closed channel

goroutine 46 [running]:
go.k6.io/k6/stats.PushIfNotDone(...)
        go.k6.io/[email protected]/stats/stats.go:433
github.com/grafana/xk6-browser/common.(*NetworkManager).emitResponseReceived(0xc0010c0280, 0xc0006085b0)
        github.com/grafana/[email protected]/common/network_manager.go:131 +0x87a
github.com/grafana/xk6-browser/common.(*NetworkManager).onResponseReceived(0xc0010c0280, 0xc0005de8c0)
        github.com/grafana/[email protected]/common/network_manager.go:356 +0xc5
github.com/grafana/xk6-browser/common.(*NetworkManager).handleEvents(0xc0010c0280, 0xc00057a5a0)
        github.com/grafana/[email protected]/common/network_manager.go:245 +0x1cf
github.com/grafana/xk6-browser/common.(*NetworkManager).initEvents.func1()
        github.com/grafana/[email protected]/common/network_manager.go:220 +0x37
created by github.com/grafana/xk6-browser/common.(*NetworkManager).initEvents
        github.com/grafana/[email protected]/common/network_manager.go:219 +0x125

Here's the JS code I'm running, with the failure happening in clickBrowseDesigns (which is odd as it is very similar to the preceding clickBusinessCards).

Script
import { sleep, group } from 'k6';
import launcher from 'k6/x/browser';

import { randomIntBetween } from 'https://jslib.k6.io/k6-utils/1.1.0/index.js';

export const options = {};

let browser, context, page;

const pauseMin = 1;
const pauseMax = 1;

export default function() {
  initialize();
  
  navigateToHomepage();
  clickBusinessCards();
  clickBrowseDesigns();
  clickDesign('Standard (3.5" x 2")');
}

function initialize() {
  browser = launcher.launch('chromium', {
    args: [],
    debug: false,
    devtools: false,
    env: {},
    executablePath: null,
    headless: false,
    ignoreDefaultArgs: [],
    proxy: {},
    slowMo: '500ms',
    timeout: '30s',
  });

  context = browser.newContext({
    ignoreHTTPSErrors: true
  });

  page = context.newPage();
}

function navigateToHomepage() {
  group("Navigate to Homepage", () => {
    page.goto('https://vistaprint.ca', { waitUntil: 'domcontentloaded' });
  });

  sleep(randomIntBetween(pauseMin, pauseMax));
}

function clickBusinessCards() {
  const elem = page.$("//span[text()='Business Cards']");

  console.log(JSON.stringify(elem));

  group("Click Business Cards", () => {
    elem.click();
    
    // Wait for next page to load
    page.waitForLoadState('networkidle');
  });

  sleep(randomIntBetween(pauseMin, pauseMax));
}

function clickBrowseDesigns() {
  const elem = page.$("//a[text()='Browse designs']");

  console.log(JSON.stringify(elem));

  group("Click Browse Designs", () => {
    elem.click();
    
    page.waitForLoadState('networkidle');
  });

  sleep(randomIntBetween(pauseMin, pauseMax));
}

function clickDesign(designName) {
  // fetch all of the design options
  const designOptions = page.$("li.design-tile");
  console.log(JSON.stringify(designOptions));
  console.log(`Found ${designOptions.length} design options.`);

  console.log(`Selecting "${designName}"...`);

  JSON.stringify(designOptions);
}

This PR fixes the nil pointer issues.

@inancgumus inancgumus added the bug Something isn't working label Nov 1, 2021
@inancgumus
Copy link
Member Author

I tried this script with the initial commit (git reset --hard a59352f) but the result is similar:

invalid memory address or nil pointer

It's weird that Tom was not getting an error before. 🤷

@inancgumus
Copy link
Member Author

inancgumus commented Nov 1, 2021

I tried to fix some issues but not the panic: send on closed channel.

--> #50

@imiric Do you have any idea why k6 closes the Samples channel? Any idea when an extension can receive send on closed channel for state.Samples? I guess it happens if m.ctx is done.

sampleTags := k6stats.IntoSampleTags(&tags)
k6stats.PushIfNotDone(m.ctx, state.Samples, k6stats.ConnectedSamples{
Samples: []k6stats.Sample{

@imiric
Copy link
Contributor

imiric commented Nov 2, 2021

@inancgumus Can you reproduce the panic?

I haven't looked into this yet, but my hunch would be that there's a race condition between the extension code and the Engine shutdown, which closes the Samples channel after the globalCtx is done:
https://github.com/grafana/k6/blob/b8164eed5413732e94f0f334b9a873146bd0f58b/core/engine.go#L315-L323

So this might be a general problem all extensions would have. I'll take a deeper look later today.

We might want to have a separate issue for that, if #50 fixes the nil pointer panics.

@imiric imiric linked a pull request Nov 2, 2021 that will close this issue
@inancgumus
Copy link
Member Author

inancgumus commented Nov 2, 2021

@inancgumus Can you reproduce the panic?

Yep, I can. Can you try it on your machine? I checked the context propagation path and it seems fine. Yeah, there may be another issue.

@imiric
Copy link
Contributor

imiric commented Nov 4, 2021

@tom-miseur I'm not able to reproduce the last two issues (Cannot find context with specified id and the panic) on the latest main (9ceafb3) with your script, and AFAIK neither can Inanc. Can you try doing the same and letting us know if the issue persists? I'm not able to reproduce it on older commits either... 😕 Was the issue persistent or did it happen intermittently?

I'm making some context changes and updating the extension to the new ModulesV2 variant, which could improve things, but it's difficult to know without being able to reproduce this.

@inancgumus inancgumus changed the title Nil pointers after page switches Cannot find context with specified id Nov 8, 2021
@inancgumus
Copy link
Member Author

inancgumus commented Nov 8, 2021

We fixed the nil pointer and session context errors, but this issue persists. When I run the script, k6 throws a Cannot find context with specified id error.

After element clicks, pages do change on the opened browser. However, the page object in the script never changes. For example, after an element click, it still prints the previous page's title when I print the page title in the script.

I'm suspicious that click actions do not change page objects. Should they?

@robingustafsson Do you have an idea why the page objects never change?

@imiric
Copy link
Contributor

imiric commented Nov 8, 2021

@inancgumus Can you post Tom's script or a minimal version of it here that reproduces the Cannot find context with specified id issue?

@inancgumus
Copy link
Member Author

inancgumus commented Nov 8, 2021

@imiric It's the same script :(

@imiric
Copy link
Contributor

imiric commented Nov 8, 2021

I wasn't able to reproduce either the panic or that issue with the script from the description on Linux. It happens consistently for you on current main?

@inancgumus
Copy link
Member Author

inancgumus commented Nov 8, 2021

Yep, it happens all the time, maybe we should add a test for this.

@inancgumus inancgumus added the next Might be eligible for the next planning (not guaranteed!) label Nov 25, 2021
@inancgumus inancgumus self-assigned this Nov 25, 2021
@inancgumus inancgumus linked a pull request Dec 2, 2021 that will close this issue
inancgumus added a commit that referenced this issue Dec 2, 2021
Fixes #49

This fixes the problem to some extent and I don't know about the
implications of skipping IFrames with empty URLs. However, it
seems like fixing the problem after plenty of manual tests.
inancgumus added a commit that referenced this issue Dec 2, 2021
Fixes #49

This fixes the problem to some extent and I don't know about the
implications of skipping IFrames with empty URLs. However, it
seems like fixing the problem after plenty of manual tests.
@inancgumus
Copy link
Member Author

On hold because: #125 (comment)

@inancgumus inancgumus removed their assignment Dec 6, 2021
@inancgumus inancgumus added the blocked We need further action from something/someone to be able to work on the issue label Dec 6, 2021
inancgumus added a commit that referenced this issue Dec 8, 2021
The error was:
panic: interface conversion: interface {} is nil, not
*common.ElementHandle

The cause of the error was trying to assert a nil result
in Frame.document to *ElementHandle. Of course, this is
probably the surface error. There may be other causes
for it, or maybe not.

It was hard to test Frame, so I used an abstraction called
FrameExecutionContext. There are a lot of problems are
happening with execution contexts. See: #125 and #49, for
example. So, it's better to make them testable, starting
here.

Fixes #53
inancgumus added a commit that referenced this issue Dec 20, 2021
Fixes #49

This fixes the problem to some extent and I don't know about the
implications of skipping IFrames with empty URLs. However, it
seems like fixing the problem after plenty of manual tests.
@inancgumus inancgumus reopened this Dec 24, 2021
@inancgumus inancgumus self-assigned this Dec 27, 2021
inancgumus added a commit that referenced this issue Dec 27, 2021
Fixes #49

This fixes the problem to some extent and I don't know about the
implications of skipping IFrames with empty URLs. However, it
seems like fixing the problem after plenty of manual tests.
@inancgumus inancgumus assigned inancgumus and unassigned inancgumus Dec 28, 2021
inancgumus added a commit that referenced this issue Jan 3, 2022
Sometimes sessions get closed and they clog
the communication between frame sessions and
sessions. This usually happens when a frame
session is getting created after new frame
attachments. This was causing problems with
frame handling.

This commit prevents lagging by failing
fast when it detects a session is closed.

It also changes the ordering of FrameSession
init steps. The reason of putting initOptions
last is: It was propagating frame events
before the frame is ready to be used.
@inancgumus inancgumus linked a pull request Jan 3, 2022 that will close this issue
@inancgumus inancgumus removed the blocked We need further action from something/someone to be able to work on the issue label Jan 4, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working next Might be eligible for the next planning (not guaranteed!)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants