This appears to be a regressions from .31

I'm not entirely sure about this. First of all, there are no obvious candidates in .31 (at least, nothing in Collection and nothing relevant that mentions Session objects).

Also, CollectionProposals::__construct() should use a typehint on the array parameter to catch this kind of errors earlier.

That said, I think what might be happening is that Session implements ArrayAccess, which means it's not possible to use multidimensional arrays. The code is:

$session = SessionManager::getGlobalSession();
if ( !isset( $session['wsCollectionSuggestBan'] ) || $mode == 'resetbans' ) {
	$session['wsCollectionSuggestBan'] = []; // This is the property we're looking for
}

// ...
$session['wsCollectionSuggestBan'][] = $param;

// ...
$proposals = new CollectionProposals(
	$session['wsCollection'],
	$session['wsCollectionSuggestBan'], // Here we want an array
	$session['wsCollectionSuggestProp']
);

I think that line in the middle could fail with

Notice: Indirect modification of overloaded element of Foo has no effect in /in/I32hW on line 21

but I'm not finding similar notices in the logs. Also, codesearch seems to suggest that no other code is modifying 'wsCollectionSuggestBan'. I might take a closer look later.

In T275785#6862416, @Daimona wrote:

I think that line in the middle could fail with

Notice: Indirect modification of overloaded element of Foo has no effect in /in/I32hW on line 21

Never mind, this isn't true -- Session can handle this correctly based on local tests.

Also, the stack trace shows that the $mode is 'add'. My running theory is that the session value is correctly set, but then it's unset somewhere before CollectionProposals is constructed. In particular, these are the relevant lines for the 'add' mode:

SpecialCollection::addArticleFromName( NS_MAIN, $param );
self::unban( $param );

unban() does some manipulation of that session property, but it shouldn't cause it to get unset (and it won't touch it if already unset). OTOH, SpecialCollection::addArticleFromName also does some session manipulation, and I think it might be removing the value from the session. This was another cursory look, I still need time to take a closer look to that method in SpecialCollection and its callees :-)

Change 715790 had a related patch set uploaded (by Umherirrender; author: Umherirrender):

[mediawiki/extensions/Collection@master] Use sane defaults for invalid types in CollectionProposals

https://gerrit.wikimedia.org/r/715790

Change 715790 merged by jenkins-bot:

[mediawiki/extensions/Collection@master] Use sensible defaults for invalid types in CollectionProposals

https://gerrit.wikimedia.org/r/715790