It is not entierly clear why the error happens. A hint might be that the last item that was correctly processed was followed by a gap in the item list. Q7246 is fine, Q7247 for some reason does not exist (it was _not_ deleted, it just never was created), then the row continues with Q7248.

I have locally changed the script so if $local is found to be an instance of Closure, the output will be skipped.

We have to use the TTL export to initialize our Wikibase's SPARQL query endpoint.

This doesn’t seem like a purtle issue – something must be calling a purtle method incorrectly. Can you provide a full stack trace of the error, so we can see where the call comes from? It would also be useful to know what the closure evaluates to (try calling it with no arguments).

I am unfortunately not savvy enough to provide a stack trace, but have the (amateurish) patch that solves the issue for Rhizome available on GitHub: https://github.com/rhizomedotorg/wikibase-docker/commit/d810a86021490b2a9aa99f476251fd4ac754bcb9 (both @Lucas_Werkmeister_WMDE and @Addshore are invited to the repo)

I’m back from vacation now, and my invitation to the repo/org expired.

⛱ re-sent invite 🏖

Can you try adding something like this?

			if ( $local instanceof \Closure ) {
				$function = new \ReflectionFunction( $local );
				fwrite( STDERR, $function->getFileName() . PHP_EOL );
				fwrite( STDERR, $function->getStartLine() . PHP_EOL );
				fwrite( STDERR, $function->getEndLine() . PHP_EOL );
				return;
			}

That should hopefully tell us what kind of closure we’re looking at.