This needs to be fixed in includes/engines/LuaCommon/TitleLibrary.php if someone is interested. In PHP side, standalone '#' string will construct a valid title object with title text morphed to empty string (because of stripping of illegal chars) which will cause it to eventually just redirects to whatever the mainpage is.

Note on my change to the title: mw.title.new("#") returns an object, but accessing any of the expensive fields causes an error to be thrown in mw.title.lua. When I type the following lines one-by-one into the console, the field accesses on the title object all throw the same error:

title = mw.title.new("#")
= title.exists
= title.id
= title.isRedirect
= title.contentModel

This can be fixed in mw.title.lua by checking that php.getExpensiveData( t.fullText ) on line 209 is not nil before iterating over it with pairs.

In T240678#6506685, @Erutuon wrote:

mw.title.new("#")

It does not return an object, there is no object to return

This can be fixed in mw.title.lua by checking that php.getExpensiveData( t.fullText ) on line 209 is not nil before iterating over it with pairs.

That's not the root cause of the problem, it merely propagates to there, and so that's no right place to tackle the issue

In T240678#6507420, @Ammarpad wrote:

In T240678#6506685, @Erutuon wrote:

mw.title.new("#")

It does not return an object, there is no object to return

I don't understand. By an object I mean a Lua table, and mw.title.new("#") is certainly a table at the moment because this assertion succeeds:

assert(type(mw.title.new("#")) == "table")

This can be fixed in mw.title.lua by checking that php.getExpensiveData( t.fullText ) on line 209 is not nil before iterating over it with pairs.

That's not the root cause of the problem, it merely propagates to there, and so that's no right place to tackle the issue

Right, I guess it would be a bandaid. Ideally mw.title.new("#") should return nil rather than a table, as the documentation says it does. I'm not familiar enough with PHP or the MediaWiki codebase to fix this myself.

I think I fixed this... at sometime

There are two ways to fix it, either to return null or to behave as PH/JS do, i.e return a Title object that will eventually redirects to main page, I think that's better.

The issue in the Lua code is triggered because of:

			if k == 'fullText' then
				if data.fragment ~= '' then
					return data.prefixedText .. '#' .. data.fragment
				else
					return data.prefixedText
				end
			end

There is no fragment, so an empty string is returned, which is an invalid title in PHP (it is surprising to me that # is a "valid" title in PHP, but that's a separate issue).

My preferred solution would be to have TitleLibrary::newTitle() check if $title->getFullText() === '' and if so, return [ null ] (aka nil). But it's unclear to me how much breakage that would cause, like for cases where someone is only accessing inexpensive data, which would now begin to fail. Is it reasonable to assume that people passing input to mw.title.new() are properly checking for nil, as is documented?

I also think it's a bug that getExpensiveData can return nil, but none of the Lua code handles it.