couldn't load module instance while resolving identifier %q

Error message

couldn't load module instance while resolving identifier %q - this is a k6 bug , please report it (https://github.com/grafana/k6/issues)

What it means

During bundle creation, resolving an exported binding walks the ESM module graph and fetches the live module instance from the runtime. If the resolved export's module has no instance, k6 panics with an explicit 'this is a k6 bug, please report' message — by construction every resolved export should belong to an instantiated module, so this indicates an engine defect, not user error, though exotic scripts can provoke it.

Source

Thrown at internal/js/bundle.go:75

	mainModule   sobek.ModuleRecord
	moduleVUImpl *moduleVUImpl
}

func (bi *BundleInstance) getCallableExport(name string) sobek.Callable {
	fn, ok := sobek.AssertFunction(bi.getExported(name))
	_ = ok // TODO maybe return it
	return fn
}

func (bi *BundleInstance) getExported(name string) sobek.Value {
	re, ambigiuous := bi.mainModule.ResolveExport(name)
	if ambigiuous || re == nil {
		return nil
	}
	moduleInstance := bi.Runtime.GetModuleInstance(re.Module)
	if moduleInstance == nil {
		panic(fmt.Sprintf("couldn't load module instance while resolving identifier %q - this is a k6 bug "+
			", please report it (https://github.com/grafana/k6/issues)", re.BindingName))
	}

	return moduleInstance.GetBindingValue(re.BindingName)
}

// NewBundle creates a new bundle from a source file and a filesystem.
func NewBundle(
	piState *lib.TestPreInitState, src *loader.SourceData, filesystems map[string]fsext.Fs, mr *modules.ModuleResolver,
) (*Bundle, error) {
	return newBundle(piState, src, filesystems, lib.Options{}, true, mr)
}

func newBundle(
	piState *lib.TestPreInitState, src *loader.SourceData, filesystems map[string]fsext.Fs,
	options lib.Options, updateOptions bool, // TODO: try to figure out a way to not need both
	moduleResolver *modules.ModuleResolver,
) (*Bundle, error) {

View on GitHub (pinned to 93accf6570)

Solutions

Update to the latest k6 patch release — several Sobek module-resolution bugs were fixed after the transition
Minimize the repro (one import chain) and report it at https://github.com/grafana/k6/issues with the script and k6 version, as the panic requests
Work around by restructuring imports: break circular dependencies, import directly from the defining module instead of a re-exporting barrel, or re-export with explicit 'export { x } from ...'
If a transpiler is involved, simplify its module output to plain ESM and retest

Example fix

// before: circular re-export chain that can hit the bug
// a.js: export { helper } from './b.js'
// b.js: import { other } from './a.js'; export function helper(){ return other(); }

// after: break the cycle; import from the defining module directly
// a.js: export function other(){ ... }
// b.js: import { other } from './a.js'; export function helper(){ return other(); }

Defensive patterns

Strategy: try-catch

Validate before calling

// not user-preventable; minimize the module graph instead
// avoid circular re-export chains before bundling
// check: k6 inspect script.js runs bundle creation cheaply in CI

Try / catch

// Go (embedding k6 as a library): wrap NewBundle
b, err := js.NewBundle(piState, src, fs, resolver)
if err != nil { return fmt.Errorf("bundle creation failed (possible k6 bug, see https://github.com/grafana/k6/issues): %w", err) }

Prevention

Pin a known-good k6 version; retest bundle-sensitive scripts on upgrades
Avoid circular imports and deep re-export barrel files in ESM scripts
Import from defining modules directly rather than through index re-exports
When hit, minimize the import chain and report it upstream with the version

When it happens

Trigger: Complex ESM graphs: circular imports combined with re-exports, import.resolveExport finding a binding in a module that was never instantiated, or mixed CommonJS/ESM bridging in k6 >= v0.53's Sobek module runtime. Fires at script load/bundling time (k6 run/archive) when getExported resolves a top-level identifier like the default export.

Common situations: Upgrading k6 across the Goja->Sobek module-runtime transition and hitting a regression; scripts using barrel files (index.js re-exporting many modules) with cycles; local imports (./file.js) plus remote imports mixed in one graph; cutting-edge TypeScript/transpiled output patterns. The error text itself directs users to the GitHub issue tracker because k6 maintainers want reproducers.

Related errors

AI-assisted analysis of grafana/k6@93accf6570 (2026-08-15). Data as JSON: /api/errors/90a8e8350ff973a3. Report an issue: GitHub.